Announcement: there is an English version of this forum on Hallo, hier im Forum gibt es Menschen, die -- wie auch ich -- einen oder mehrere öffentliche Webserver betreiben und deren Logdate(i)en dabei von allerlei "besonderen Menschen" überflutet werden. Meine Fragen ist: tut Ihr etwas dagegen? Wenn ja, was? Lieben Dank, Sheeva
:
Verschoben durch Moderator
Hä? Man kann Logfiles auswerten und auch löschen. Ich verstehe das Problem nicht.
Nicht loggen und alles mit Eingaben wasserdicht halten.
Gustl B. schrieb: > Man kann Logfiles auswerten und auch löschen. Das stimmt, aber... > Ich verstehe das Problem nicht. Wie machst Du die Auswertung, und was machst Du dann mit den Ergebnissen?
* log2ban * fail2ban https://wiki.ubuntuusers.de/fail2ban/ * Beitrag "Netzwerkangriff" * Beitrag "Ubuntu Linux : fail2ban richtig konfiguriert?"
:
Bearbeitet durch User
Logfile analysieren und dann handeln. Wahrscheinlich reicht Dein Platz nicht für unendliche Logfiles? Logfiles gehören eigentlich auf einen anderen Server, um nach einem Störfall noch nachsehen zu können.
Forum: Mikrocontroller und Digitale Elektronik?
Lieben Dank für Eure Antworten. Allerdings hab' ich durchaus einige Gigabyte für Logs übrig, und die Größe derselben ist auch nicht mein Problem. log2ban und fail2ban kenne ich auch schon, danke für die Hinweise. Mein Problem ist vielmehr das: wie unterscheide ich (bei der Analyse meiner Logs) Freund und Feind? Also legitime User und A-löcher?
Sheeva P. schrieb: > legitime User und A-löcher Wahrscheinlich mit verschiedenen schönen Scripten und z.B. grep A-l*cher* > dieseAheute.txt?
Ich betreue mit einer Kollegin 3 öffentliche Webserver. Wir werten access.log, error.log von Apache bzw Nginx und fail2ban aus. Radikales Vorgehen: alle IPs aus RU/BY/CN/HK sind auf der Firewall, und zwar für immer; alle IPs die wirklich aggressive Anfragen stellen sind auf der Firewall, mindestens 1 Jahr, bei Wiederholung für immer. Fail2ban auf SSH gleich für immer (SSH liegt nicht auf Port 22). Die Firewall wird täglich mindestens 1x erneuert, das sind inzwischen etliche Tausend IP-Bereiche, mindestens /24, oft sogar /16, etc. Tägliches Backup des Servers ist Pflicht, nach Änderungen ggf auch 2x. Macht Arbeit, wem das zu viel ist soll's lassen.
:
Bearbeitet durch User
Alle verdächtigen IPs sperren kann viel Admin-Arbeit bedeuten, da manche Leute gemeinsam diese eine IP benutzen könnten. Schöner wäre den Bösewichten Zeit stehlen und Spaß verderben, indem man manche ihrer Aktionen erst nach Minuten od. Stunden oder einer Eingabe wieder erlaubt.
:
Bearbeitet durch User
> Mein Problem ist vielmehr das: wie unterscheide ich (bei der Analyse > meiner Logs) Freund und Feind? Also legitime User und A-löcher? Mit Methoden aus der "Intrusion detection" ? * https://dcid.me/notes/log-analysis-for-intrusion-detection * https://www.feistyduck.com/library/apache-security/online/apachesc-CHP-12.html "Nomen est omen" -> Manche Feinde sind am Namen erkennbar, da gibt es Listen bekannter Bösewichter (IP) oder clients. Und manchmal ist die angefragte URL verdächtig, wenn also einer nach password.txt oder ähnlichen fragt ... Und Bösewichter sind meist script-kiddies, aus den Anfragen kann man also herauslesen, das es sich um scripte handelt (schnelles menschenuntypisches timing). Und dann könnte man sich davon leiten lassen, das friedliche Menschen abends schlafen. Wenn also das Reverse-IP-DNS eine geo-reference eine timezone ermittelt in der eigentlich Schalfenmszeit ist ... (OK, das kann auch zu false positive führen). ...
:
Bearbeitet durch User
Cloudflare? Bei mir funktioniert's... der gratis Service reicht. Detailliertes usertracking braucht man ja nicht wirklich. 73
Stephan S. schrieb: > Ich betreue mit einer Kollegin 3 öffentliche Webserver. Wir werten > access.log, error.log von Apache bzw Nginx und fail2ban aus. > > Radikales Vorgehen: alle IPs aus RU/BY/CN/HK sind auf der Firewall, und > zwar für immer; alle IPs die wirklich aggressive Anfragen stellen sind > auf der Firewall, mindestens 1 Jahr, bei Wiederholung für immer. > Fail2ban auf SSH gleich für immer (SSH liegt nicht auf Port 22). Das würde ich gerne machen, kann aber nicht. Mein Auftraggeber veranstaltet internationale Fachkongresse, da sind Wissenschaffende aus aller Herren Länder vertreten, sollen es sein, und bleiben. :-) Andererseits hast Du mich auf ein paar gute Ideen gebracht, lieben Dank! Man könnte ja... okay, ich habe eine Client-IP. Was ist, wenn die vermehrt HTTP [45]xx anstelle von [23]yy wirft, weil da einer die Muster veralteter Versionen von (zum Beispiel) Wordpress abklappert? (Zum Beispiel halt) Entschuldigt bitte, ich... denke eher darüber nach, wie ich die Schmutzfinken erkennen kann. Erst wenn ich das kann, darf ich mir Gedanken machen, wie ich mit erkannten Schmutzfinken verfahre.
Lu schrieb: > Wahrscheinlich mit verschiedenen schönen Scripten und z.B. > grep A-l*cher* > dieseAheute.txt? Mir sind auch sort(1) und uniq(1) bekannt. :-)
Sheeva P. schrieb: > tut Ihr etwas dagegen? Wenn ja, was? Nicht loggen. Wozu eigentlich? Sheeva P. schrieb: > wie unterscheide ich (bei der Analyse > meiner Logs) Freund und Feind? Wenn du das nicht kannst, woher weißt du dann, daß es "Feinde" sind? Sheeva P. schrieb: > was machst Du dann mit den Ergebnissen? Ja eben. Was? Ich habe Logs auf Webservern die ich betreibe, in ganz ganz seltenen Fällen zum Debuggen benötigt. Ansonsten habe ich (bzw. ein cronjob) die Logs nur gelöscht. Deswegen bin ich seit einiger Zeit dazu übergegangen, gar keine Logs mehr zu schreiben sobald der Service läuft. Für die Firma, bei der ich mir meine Sporen verdient habe (lang ists her) habe ich die Logs einmal im Monat durch ein Analysetool gedreht. Clickstreams, Landing pages, originating TLDs und lauter so ein Zeugs. Keine Ahnung ob die Reports jemand gelesen hat. Wenn ja, dann nur Marketingdroiden... ismirsowasvonegal <shrug>
Sheeva P. schrieb: > Man könnte ja... okay, ich habe eine Client-IP. Was ist, wenn die > vermehrt HTTP [45]xx anstelle von [23]yy wirft, weil da einer die Muster > veralteter Versionen von (zum Beispiel) Wordpress abklappert? (Zum > Beispiel halt) Ist eine gängige Methode, nach x-mal 4xx (bei 5xx wäre ich vorsichtig) wird erstmal temporär gesperrt. Dann musst Du aber a) bei Änderungen an der Website gut aufpassen, dass es keine fehlenden Bilder o.dgl. gibt und b) Fälle wie robots.txt, favicon.ico und irgendwelches Apple-Touch-Icon-Geraffel berücksichtigen (oder die Schwelle hoch genug setzen). Als Kollateralschäden könntest Du andere Kunden hinter (CG)NAT-Gateways erwischen, aber das dürfte nur bei stark frequentierten Websites ein Hindernis sein.
> alle IPs die wirklich aggressive Anfragen stellen sind > auf der Firewall, mindestens 1 Jahr, bei Wiederholung für immer Das ist totaler Blödsinn. Wenn jemand wirklich aggressiv angreift, dann macht der das nicht mit seiner echten IP, sondern mit einer gespooften, über ein paar Proxies oder mit einer VPN-Lösung. Wenn man die IP, über die derjenige dann reinkommt, für längere Zeit blockiert, dann trifft man damit alles mögliche, aber ganz sicher nicht den Angreifer. In der Folge ärgern sich dann evtl. etliche ehrliche User über Deine ach so tolle Sperre, die nur zufällig über die gleiche IP reinkommen, die zuvor für einen Angriff genutzt wurde. Das ist total toll und für die Popularität einer Seite ein großes Plus. Ich möchte da nicht den Support für machen. Zum Thema allgemein: Man muss schauen welche Ziele angegriffen werden und entsprechend handeln. Die meisten Angriffe, die ich sehe, sind immer noch dumme Script-Scans nach irgendwelchen Programmen oder Admin-Tools im Web-Ordner. Diese sind mir komplett egal, solange diese Tools entsprechend geupdatet sind. Die meisten der angegriffenen Tools nutzt man sowieso nicht oder man braucht auch nur den Standard-Ordnernamen zu ändern, damit solche Scans ins Leere laufen. Bei besser gezielten Angriffen z.B. auf eine Passwort-Abfrage, kann man sehr gut Teergruben einsetzen. Also den ganzen Prozess der Passwort-Abfrage künstlich so verlangsamen, daß sich kein Bruteforce- oder Wörterbuchangriff mehr lohnt. Notfalls auch nach einer größeren Anzahl Fehlversuche über einen zweiten Kanal, wie beispielsweise einen Code per eMail verschicken, der zusätzlich abgefragt wird. Mit sowas aber wieder Vorsicht, denn das nervt den ehrlichen User und es darf sich nichts an der Ausgabe des Webservers ändern, was darauf schließen lässt, daß man das korrekte Passwort hat. Sondern nach vielleicht 10 Fehlversuchen nur noch ein Bildschirm, daß eine eMail an das Postfach gegangen ist, in der weitere Schritte zum Wiederherstellen eines vergessenen Kennworts stehen oder so. Diese eMail darf natürlich nicht jedes Mal tatsächlich versandt werden, sondern nur wenn das korrekte Kennwort eingegeben wurde (aber die erlaubten Fehlversuche voll sind) oder wenn der echte User das will (z.B. Link auf Kennwort vergessen anklickt). Dieser Umweg wird den User auch nerven, ist aber besser als ein verlorener Account.
Ben B. schrieb: >> alle IPs die wirklich aggressive Anfragen stellen sind >> auf der Firewall, mindestens 1 Jahr, bei Wiederholung für immer > Das ist totaler Blödsinn. Wenn jemand wirklich aggressiv angreift, dann > macht der das nicht mit seiner echten IP, sondern mit einer gespooften, > über ein paar Proxies oder mit einer VPN-Lösung. Da hast Du natürlich theoretisch recht, es sind jedoch immer die gleichen Proxies und Hoster, über die die Angriffe laufen. Und die sperren wir, weil eine Beschwerde über Abuse von denen wohl nicht mal gelesen wird (einige haben im Whois nicht mal eine Abuse-Email angegeben).
Sheeva P. schrieb: > Meine Fragen ist: tut Ihr etwas dagegen? Wenn ja, was? Hallo Sheeva, schau mal hier: https://www.dshield.org/ . Und|Oder einen Honeypot installieren und zusammen mit vielen anderen mittels Internet Storm Center rechtzeitig Attacken erkennen und Gegenmaßnahmen ergreifen. Bei mir laufen alle paar Minuten Scripts, die die Logfiles parsen und gewisse Suchmuster aufstöbern, die IP-Adressse extrahieren, in eine DB schreiben und von dort aus einen Export für das RULESET herstellen, das von den »nftables« importiert wird. Das heißt, die nft-firewall wird automatisch alle paar Minuten automatisch aktualisiert (non-artificial intelligence ;-) Check-out https://isc.sans.edu/dashboard.html Damit fahre ich seit Jahren sehr gut. Liebe Grüße Karl https://de.wikipedia.org/wiki/Internet_Storm_Center
Axel S. schrieb: > Sheeva P. schrieb: >> wie unterscheide ich (bei der Analyse >> meiner Logs) Freund und Feind? > > Wenn du das nicht kannst, woher weißt du dann, dass es "Feinde" sind? Sheeva, 1. mach mal einen nmap-scan auf deinen server. Schau, welche offenen Ports du hast. Sollte da was offen sein, das du nach »draußen« gar nicht »anbieten« willst, dann hast du schon mal den ersten Anhaltspunkt, wo du ansetzen mußt. 2. Die meisten Angriffe kommen aus China, Rußland, Südafrika, Nordkorea etc. Also sperre von denen gleich ganze IP-Ranges (i.e. 1.24.0.0/13). Damit reduzierst du die Logfilegrößen schon mal um ein Drittel, wenn nicht mehr. 3. z.B. wenn jemand an Port 2137 versucht anzudocken, dann ist es kein Freund. Siehe https://www.dshield.org/diary/Guest+Diary+Using+Zeek+Snort+and+Grafana+to+Detect+Crypto+Mining+Malware/31472/ 4. Suche mit grep die Logfiles nach DPT durch und sortiere und zähle sie, dann wirst du schnell fündig, dass die meisten Versuche an all jenen Ports anzudocken, die du auf deiner Maschine nicht geöffnet hast, definitiv keine Freunde sind. Hope it helps. Liebe Grüße Karl
Sheeva P. schrieb: > Andererseits hast Du mich auf ein paar gute Ideen gebracht, lieben Dank! Vielleicht noch was: den SSH-Zugang nicht per Username/Passwort sondern ausschliesslich über Publickey mit elliptischer Kurve erlauben (und natürlich kein root), einen hohen Port für SSH (und dann nicht 222, sondern z.B. 51736) und kein FTP/FTPS (Port 21/20), sondern SFTP, SCP und rsync -e ssh (das läuft dann alles über SSH), wieder 2 Ports zu. Der hohe Port für SSH ist erstaunlich erfolgreich, ich hatte früher Port 229 und trotzdem tausende IPs in Fail2ban, jetzt in fast 4 Jahren insgesamt nur 3 (i.W. drei) Angreifer die sich die Mühe gemacht haben alle Ports abzuscannen, das dauert halt. Was noch ginge wäre Port Knocking mit dem Paket knockd, damit habe ich aber keine Erfahrung.
SSH kann man auch auf IPs beschränken. Muss die Kundschaft normalerweise nicht nutzen.
Sheeva P. schrieb: > Hallo, > > hier im Forum gibt es Menschen, die -- wie auch ich -- einen oder > mehrere öffentliche Webserver betreiben und deren Logdate(i)en dabei von > allerlei "besonderen Menschen" überflutet werden. > > Meine Fragen ist: tut Ihr etwas dagegen? Wenn ja, was? > > Lieben Dank, > Sheeva Ich hatte eine riesige händisch gepflegte IP-Sperrliste, was aber ein Kampf gegen Windmühlen war. Außerdem noch ein Script, das automatisch Tor-Server aufspürte und in die Sperrliste aufnahm. Jetzt habe ich keinen eigenen Server mehr, das Risiko wurde mir irgendwann zu groß. (prx) A. K. schrieb: > SSH kann man auch auf IPs beschränken. Muss die Kundschaft > normalerweise > nicht nutzen. Genau SSH kann man gut schützen. Es braucht nur wenige Änderungen in der Konfigurationsdatei. Bereits den Port zu ändern hält schon viele Angriffsversuche ab.
:
Bearbeitet durch User
Stephan S. schrieb: > Die Firewall wird täglich mindestens 1x erneuert, das sind inzwischen > etliche Tausend IP-Bereiche, mindestens /24, oft sogar /16 IPV6 macht ihr gar nicht? Oliver
Oliver S. schrieb: > IPV6 macht ihr gar nicht? Klar doch. Funktioniert mit nftables genauso locker wie mit ipv4. Sieht man sich aber die Logfiles auf ipv6 an, wird schnell klar, dass es besser ist, du disable ipv6 in der /etc/sysctl.conf: net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 #net.ipv6.conf.tun0.disable_ipv6 = 1 ... und gut ists. Liebe Grüße Karl
Ben B. schrieb: > Das ist totaler Blödsinn. Wenn jemand wirklich aggressiv angreift, dann > macht der das nicht mit seiner echten IP, sondern mit einer gespooften, > über ein paar Proxies oder mit einer VPN-Lösung. Man merkt, dass Du von der Praxis keine Ahnung hast. Es gibt haufenweise Adressblöcke, die seit Jahren für Angriffe eingesetzt werden. Die Eigentümer sind z.B. gelegentlich wechselnde russische Briefkastenfirmen, da kannst Du dann erahnen, was eine Mail an die Abuse-Adresse bringt. Ansonsten gibt es noch genug Hoster, denen Beschwerden egal zu sein, mir fällt da spontan ein grosser aus Frankreich ein. TOR und irgendwelche Kinder-VPNs sieht man zwar auch mal, aber das sind dann eher Forenspammer und ähnlicher Kleinkram. Tim 🔆 schrieb: > Bereits den Port zu ändern hält schon viele Angriffsversuche ab. Es bleibt leider genug übrig. Sobald einer der 24/7 aktiven Portscanner den gefunden hat, sieht man selbst Monate nach dem Dichtmachen noch gehäufte Versuche auf diesem Port.
Ben B. schrieb: > Das ist totaler Blödsinn. Finde ich gar nicht. Was wäre eine wirklich realistische Alternative für Kleinbetreiber? Dein POV ist aus Sicht einer größeren Firma. Die kleinen haben keine Loadbalancer, DMZs, eigene DNS oder HardwareFirewalls oder oder. Und: Die Verteidigung nach dem schwächsten, anzunehmenden ehrlichen User der Kette auszurichten, ist ein schwerer taktisch und strategischer Fehler. Erstens muss man seine Klientel erziehen. Gratis E-Mail-Adressen usw., die Zeit ist längst vorbei. Ich weiß, für die meisten ist es das noch immer nicht. Thema Verschlüsselung: genau die gleiche Tragödie. Willst du einen ehrlichen User zulassen, hat sich der im Netz nicht anonym von irgendwoher zu bewegen. Im Straßenverkehr hat man Nummerntafeln. Wäre im Internet mit ipvng auch möglich, weil connection-oriented und nicht wie bei ipv4 connection-less. Das ist aber ein zweischneidiges Schwert: die totale Überwachung. > Wenn jemand wirklich aggressiv angreift, dann > macht der das nicht mit seiner echten IP, sondern mit einer gespooften, > über ein paar Proxies oder mit einer VPN-Lösung. Aber nicht jene aus China, Nordkorea etc., weil VPNs (z.Tor) »sau langsam« ist und die Angreifer meist keine Menschen sind, sondern BOTs, hunderte kleine Rasbperries oder dgl. Ausserdem: was soll ein ehrlicher Chinese oder Russe oder oder oder auf deiner in deutsch gehaltenen Website finden? Also sperr das ganze Zeugs. Aber wenn jemand via abuse dir eine Mail schickt, dann werde aktiv. Und nicht im vorauseilenden Gehorsam. Und wenn jemand - normaler User - auf eine gewöhnliche kommerzielle Seite über VPN kommt, ist sie selber schuld. Meine Erfahrung ist, dass sehr viele Angreifer sich in Europa schmale, billigste vhosts bzw. Docker oder LXD-cluster mieten oder kaufen und von dort aus Angriffe starten. Wenn die dann von der Mehrheit gesperrt werden, kündigen sie diese Range und nehmen sich die nächste Range beim nächsten europäischen Provider, die voller Gier nach allem, was nach Gold glänzt, lächzen und keine Moral oder Sicherheitsbedenken haben (Dein POV?). Denk an T-Mobile u.a. und 5G und so fort. Liebe Grüße Karl
:
Bearbeitet durch User
Stephan S. schrieb: > Radikales Vorgehen: alle IPs aus RU/BY/CN/HK sind auf der Firewall, und > zwar für immer Das ist nicht nur rassistisch, sondern verhindert auch, dass unsere Landsleute selber nicht mehr zugreifen können, wenn sie mal Urlaub oder eine Geschäftsreise in ein solches Land machen.
Johnny B. schrieb: > dass unsere > Landsleute selber nicht mehr zugreifen können, Das müssen Unschuldige verstehen. Wir Einheimische müssen auch viel verstehen! MfG alterknacker
Johnny B. schrieb: > Das ist nicht nur rassistisch Bevor ich dein versuchtes Totschlagargument annehme, schau mal hier https://de.wikipedia.org/wiki/Rassismus Im Übrigen hat Rassissmus im Kontext der Selbstverteidigung aber sowas von keinen Rechtfertigungsanspruch. Egal welche Rasse angreift. Wird man angegriffen, muss man sich verteidigen. >, sondern verhindert auch, dass unsere > Landsleute Vorsicht! Rassismus? > selber nicht mehr zugreifen können, wenn sie mal Urlaub oder > eine Geschäftsreise in ein solches Land machen. Das wirft die Frage auf, wer macht Urlaub in Belaruss, in China, in Russland? Nicht in Male? ;-) Und im Urlaub surft frau dann auf dt. Websites, um was zu tun? Einzukaufen? Wird wohl bis nach dem Urlaub warten können, oder? Und Geschäftsreisende verwenden Firmen-VPNs. Ausser du bist ranghoher Offizier der Bundeswehr und kannst damit nicht umgehen. Wo liegt das Problem? Zusammengefasst: deine Argumente sind nicht stimmig. Liebe Grüße Karl
:
Bearbeitet durch User
Hallo, vielen lieben Dank für Euren Input. Vielen Dank auch für die Hinweise zur Absicherung von SSH, die habe ich allerdings bereits umgesetzt -- für einen Einsteiger wären das aber natürlich trotzdem wertvolle Hinweise und eventuell stolpert ja mal einer über diesen Thread. Zudem hat mich insbesondere der Hinweis auf dshield [1] zu einigen weiteren Fundstellen geführt, insbesondere FireHOL [2], die verschiedene Blocklisten zusammen in einem Github-Repository aggregieren [3]. Die werde ich mal in eine OpenSearch-Instanz überführen und dann mit meinen aktuellen Logs und etwas Statistik herausfinden, ob und wie nützlich diese Listen sind. Im Moment verfolge ich allerdings gedanklich einen mehrstufigen Ansatz: Positiv- und Negativlisten, ein oder mehrere der online angebotenen Listen etwa von FireHOL, und dazu Counter auf den HTTP Response Codes. Diese Daten werden dann mit einer Fuzzy Logik auf einen einzelnen Score-Wert reduziert, und beim Überschreiten konfigurierbarer Schwellwerte bekommt der Client den HTTP-Statuscode 403 Forbidden (oder hat jemand einen besseren Vorschlag?) sowie eine entsprechende Fehlermeldung. Ob ich vor Rückgabe des Fehlercode noch ein bisschen abwarte, um den Client ein wenig zu verlangsamen... das schauen wir dann mal. Zunächst geht es allerdings ohnehin nur um das Sammeln von Daten. Die werden dann ausgewertet, um meine Schwellwerte zu ermitteln. Vielen lieben Dank für die rege Teilnahme an der Diskussion und die wertvollen Hinweise. Ich wünsche Euch allen ein schönes Wochenende! :-) [1] https://dshield.org/ [2] https://firehol.org/ [3] https://github.com/firehol/blocklist-ipsets
Wer schreibt denn heute noch eMails an irgendwelche Abuse-Adressen? Da würde ich nicht vom geringsten Erfolg ausgehen bzw. eher sende ich dadurch noch eine Art Empfangsbestätigung und mache mich damit möglicherweise als Ziel noch attraktiver. Dafür ist mir meine Zeit zu schade.
Ben B. schrieb: > Wer schreibt denn heute noch eMails an irgendwelche Abuse-Adressen? Da > würde ich nicht vom geringsten Erfolg ausgehen Und wieder einmal merkt man, dass Du keine Ahnung von der Praxis hast. Es gibt Hoster mit gutem Abuse-Handling, es gibt Hoster mit schlechtem Abuse-Handling, und es gibt Bulletproof- und Fake-Hoster. Je nach Kategorie tut oder lässt man das. Positiv kann ich z.B. Hetzner erwähnen. Man muss zwar ein nerviges Web-Formular benutzen, dafür kann man aber explizit festlegen, welche Daten deren Kunde bekommt, im Zweifelsfall nur die Beschreibung und (anonymisierte) Logfiles. Und bisher war nach dem Feedback, dass der Fall erledigt ist, auch immer tatsächlich Ruhe. Ben B. schrieb: > eine Art Empfangsbestätigung Wenn man für Beschwerden auch selbst eine Abuse-Adresse verwendet, ist das nicht das Thema, die werden selbst bei öffentlicher Auffindbarkeit (Whois-Datenbank) äusserst selten vollgespammt.
Ben B. schrieb: > Wer schreibt denn heute noch eMails an irgendwelche Abuse-Adressen? Da > würde ich nicht vom geringsten Erfolg ausgehen bzw. eher sende ich > dadurch noch eine Art Empfangsbestätigung und mache mich damit > möglicherweise als Ziel noch attraktiver. Dafür ist mir meine Zeit zu > schade. Das bringt es in der Tat nicht. Ich hatte damit überhaupt nur ein einziges Mal Erfolg, bei einem Schweizer Internetprovider. Die haben den Störer tatsächlich verwarnt und ich hatte seitdem Ruhe. Edit: Habe eben nachgesehen, Bluewin war der Provider. Die haben mein Anliegen total ernst genommen, nach ein Nutzer mein Forum wochenlang terrorisiert hatte.
:
Bearbeitet durch User
Ben B. schrieb: > Wer schreibt denn heute noch eMails an irgendwelche Abuse-Adressen? Kommt etwa im Rahmen von Responsible Disclosure vor.
Anstelle Log files alle minuten zu scannen, kann man auch gleich einen proxy einsetzen, welcher alle Anfragen auseinander nimmt und validiert.
Beim heute nahezu durchweg genutzten SSL gibt's aber nicht viel zu analysieren, ohne die Verschlüsselung im Proxy aufzubrechen. Will man das nicht, ist das Log ergiebiger. Logs kann man u.U. live mitlesen, muss sie nicht scannen.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Logs kann man u.U. live mitlesen, muss sie nicht scannen. Richtig, wenn man sonst nichts zu tun hat. Der TO hat einige Webserver nicht bloß einen. Und wie viel glaubst du, wirst du selbst manuell erwischen? Human visual pattern-matcher? Echt? Nur um einer Maschine - wofür sie gemacht ist - das Scannen zu ersparen? Liebe Grüße Karl
Pandur S. schrieb: > Anstelle Log files alle minuten zu scannen, kann man auch gleich einen > proxy einsetzen, welcher alle Anfragen auseinander nimmt und validiert. Unnötiger Aufwand. So kommen aus Webserver-Sicht alle Connections vom Proxy, sofern man nicht wieder trickst, um die echte Client-IP per Header mitzuliefern. Elegantere Methode: Webserver in eine Pipe loggen lassen.
Pandur S. schrieb: > Anstelle Log files alle minuten zu scannen, kann man auch gleich einen > proxy einsetzen, welcher alle Anfragen auseinander nimmt und validiert. Der TO hat mehrere Webserver. Vermutlich nicht bei ein und dem Selben Hoster. Das heißt, für jeden Webserver einen Proxy bauen. Womöglich noch am selben vhost laufen lassen. Wie sieht das Configuration-Management aus? Was hast du gegen scannen? Liebe Grüße Karl
Karl E. schrieb: > Und wie viel glaubst du, wirst du selbst manuell erwischen? Human visual > pattern-matcher? Echt? Nur um einer Maschine - wofür sie gemacht ist - > das Scannen zu ersparen? Ich glaube, Du hast nicht ganz begriffen, was er mit "Mitlesen" gemeint hat.
Hmmm schrieb: > Ich glaube, Du hast nicht ganz begriffen, was er mit "Mitlesen" gemeint > hat. (prx) A. K. schrieb: > Logs kann man u.U. live mitlesen, muss sie nicht scannen. Erklärs mir. Liebe Grüße Karl
Karl E. schrieb: > (prx) A. K. schrieb: >> Logs kann man u.U. live mitlesen, muss sie nicht scannen. > > Erklärs mir. Nicht alle paar Minuten das Logfile scannen, sondern analog zu "tail -f" live mitlesen. Also mit read(2), nicht mit den Augen.
Hmmm schrieb: > Unnötiger Aufwand. So kommen aus Webserver-Sicht alle Connections vom > Proxy, sofern man nicht wieder trickst, um die echte Client-IP per > Header mitzuliefern. Ist keine Trickserei. Z.B. bei HaProxy ist das nur eine Zeile Konfiguration. > Elegantere Methode: Webserver in eine Pipe loggen lassen. Und dann? Live mitlesen? Liebe Grüße Karl
Hmmm schrieb: > Elegantere Methode: Webserver in eine Pipe loggen lassen. Oder auf Syslog, oder an einen Log-Agent. Professionell werden Logs zentral gesammelt.
(prx) A. K. schrieb: > Ich hatte dabei Automaten im Auge. Das muss ja echt weh tun. ;-) Liebe Grüße Karl
(prx) A. K. schrieb: > Oder auf Syslog, oder an einen Log-Agent. Professionell werden Logs > zentral gesammelt. Ja sicher doch. Und was dann am Ende? Liebe Grüße Karl
Karl E. schrieb: > Ist keine Trickserei. Z.B. bei HaProxy ist das nur eine Zeile > Konfiguration. Trickserei bleibt es trotzdem. Der Webserver muss schliesslich auch mitspielen, Stichwort (Fast)CGI und REMOTE_ADDR. Karl E. schrieb: >> Elegantere Methode: Webserver in eine Pipe loggen lassen. > > Und dann? Live mitlesen? Genau das. Auch das nicht mit den Augen, versteht sich. Ist eigentlich recht trivial: 4xx-Errors für eine Weile cachen, bei Überschreitung einer gewissen Anzahl pro Host und Zeiteinheit Sanktionen (z.B. lokale Firewall-Rule) auslösen, ggf. nach einem Timeout wieder freigeben.
(prx) A. K. schrieb: > Software, die sich der Analyse widmet. Aber doch nicht am Production-Host?! Liebe Grüße Karl
Hmmm schrieb: > Trickserei bleibt es trotzdem. Der Webserver muss schliesslich auch > mitspielen, Stichwort (Fast)CGI und REMOTE_ADDR. Keine Trickserei. Konfiguration. Liebe Grüße Karl
Karl E. schrieb: > Keine Trickserei. Konfiguration. Protokollseitig ist es Trickserei. Aber Du scheinst einfach gerne dagegen zu sein.
Hmmm schrieb: > Unnötiger Aufwand. So kommen aus Webserver-Sicht alle Connections vom > Proxy, sofern man nicht wieder trickst, um die echte Client-IP per > Header mitzuliefern. Transparente Proxies treten nicht als Proxy in Erscheinung, sondern bleiben für HTTP unsichtbar. Enterprise Firewalls mit Decryption arbeiten so, sie brechen SSL auf und untersuchen die Inhalte.
(prx) A. K. schrieb: > Transparente Proxies treten nicht als Proxy in Erscheinung, sondern > bleiben für HTTP unsichtbar. Ja, ich ging jetzt von HTTPS aus, und da geht's eben nicht transparent.
(prx) A. K. schrieb: > Software, die sich der Analyse widmet. Also doch wieder nur die halbe Miete. Das meint, Mensch muss dann nochmal drüber gehen, entscheiden, händisch sperren etc. Also ich lass das die Scripts alle paar Minuten machen. BTW. Verteilte Systeme zentral loggen lassen, alles recht und schön. Ein kleiner Webhostbetreiber kann das nicht. Vielleicht kann der TO ja a bisschen mehr über seine Anforderungen, seine Topographie erzählen, was die Sache besser einschätzen lässt, was vorteilhafter für ihn wäre. Liebe Grüße Karl
Hmmm schrieb: > Ja, ich ging jetzt von HTTPS aus, und da geht's eben nicht transparent. Doch. Wie soeben geschrieben. Nur bei outbound traffic wird es am Zertifikat deutlich, inbound nicht.
:
Bearbeitet durch User
Hmmm schrieb: > (prx) A. K. schrieb: >> Transparente Proxies treten nicht als Proxy in Erscheinung, sondern >> bleiben für HTTP unsichtbar. > > Ja, ich ging jetzt von HTTPS aus, und da geht's eben nicht transparent. Womit also die Frage des tatsächlichen Aufwandes in Relation zum Nutzen steht. Proxies aufsetzen, auf jeden Production-Host vor dem Webserver, zentral loggen lassen irgendwohin (NOC - das ein kleiner nicht hat), Analysesoftware (teuer) und dann noch zusätzlich manuelle Arbeit um zu entscheiden, was OK geht und was nicht und dann die jeweiligen Produktion-Host-Firewalls entsprechend anpassen. Mann-O-Mann. Liebe Grüße Karl
Karl E. schrieb: > Also doch wieder nur die halbe Miete. Wenn es mehrere Wege gibt, die man verfolgen kann, muss man sich gerade bei diesem Thema nicht zwingend für einen einzigen entscheiden.
Hmmm schrieb: > Protokollseitig ist es Trickserei. Aber Du scheinst einfach gerne > dagegen zu sein. Wogegen bin ich jetzt genau? Liebe Grüße Karl
Karl E. schrieb: > Womit also die Frage des tatsächlichen Aufwandes in Relation zum Nutzen > steht. Ja, der sinnvolle Aufwand hängt ein wenig von der Größe des Unternehmens ab.
Karl E. schrieb: > Analysesoftware (teuer) Nicht zwingend. Gibt einige Open Source dazu, gerade was Log-Konsolidierung und Darstellung angeht.
(prx) A. K. schrieb: > Hmmm schrieb: >> Ja, ich ging jetzt von HTTPS aus, und da geht's eben nicht transparent. > > Doch. Achso, Du meinst quasi "halbtransparent", die TLS-Connection endet beim Transparent Proxy, der ein passendes Zertifikat hat und dem echten Server gegenüber dann die Client-IP spooft? Das geht natürlich, und aus HTTP-Sicht bleibt es transparent.
(prx) A. K. schrieb: > Wenn es mehrere Wege gibt, die man verfolgen kann, muss man sich gerade > bei diesem Thema nicht zwingend für einen einzigen entscheiden. Lese noch einmal gaaaanz oben den Ausgangspunkt vom TO. Versuch dich in seine Lage zu versetzen. Und allen Anscheines ist er auch kein Systemadmin oder so. Also Relation zu Aufwand und Nutzen ist hier wichtig. Aber am Einfachsten ist, du fragst ihn mal selbst. Liebe Grüße Karl
Hmmm schrieb: > Achso, Du meinst quasi "halbtransparent", die TLS-Connection endet beim > Transparent Proxy, der ein passendes Zertifikat hat und dem echten > Server gegenüber dann die Client-IP spooft? Das geht natürlich, und aus > HTTP-Sicht bleibt es transparent. Ja. Und wenn der kein Let's Encrypt versteht, fällt dieser günstige Weg, an Zertifikate zu kommen, vielleicht flach. Karl E. schrieb: > Also Relation zu Aufwand und Nutzen ist hier wichtig. Ja. Wie bereits geschrieben.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Beim heute nahezu durchweg genutzten SSL gibt's aber nicht viel zu > analysieren, ohne die Verschlüsselung im Proxy aufzubrechen. Will man > das nicht, ist das Log ergiebiger. > > Logs kann man u.U. live mitlesen, muss sie nicht scannen. Jetzt hatte ich schon gedacht, der Thread sei beendet, schon nimmt er eine augesprochen interessante Wendung. Deswegen möchte ich zunächst kurz etwas mehr zur Infrastruktur sagen, was mir für die ursprüngliche Frage, die Freund-Feind-Erkennung, unwichtig erschien. Bei den Webservern handelt es sich in meinem Fall um einen Docker Swarm Cluster mit einem Manager- und drei Worker Nodes, auf dem Manager Node ist Traefik als Reverse Proxy ausgerollt. Der gesamte Cluster und alle darauf laufenden Applikationen werden ab Oberkante SSH mit Ansible ausgerollt und konfiguriert. Der Reverse Proxy kümmert sich um den gesamten externen Verkehr über HTTP (welches automatisch auf HTTPS umgeleitet wird) sowie um Beschaffung und Erneuerung von TLS-Zertifikaten von Letsencrypt, das Swarm Routing Mesh wird nicht verwendet. Die internen Netzwerke des Clusters werden von Docker Swarm symmetrisch mit AES verschlüsselt, und alle zwölf Stunden findet ein automatischer Schlüsseltausch statt. Alle Nodes des Cluster loggen über den systemd-journal-remote auf den Manager. Der geplante Produktionscluster soll einen eigenen Loghost, mehrere Manager und eine Floating IP-Adresse haben. Okay, genug Bullshit-Bingo, kommen wir wieder auf die Sache mit den Logs zurück. Tatsache ist, daß ich die Systemlogs über den Docker-Socket auf dem Manager, den journald oder rsyslog live mitlesen kann. Außerdem bietet mir Traefik ein interessantes Feature namens ForwardAuth [1], mit dem ich alle Requests mit der Middleware zuerst an einen beliebigen Dienst weiterleiten kann, und je nach Antwort dieses Dienstes reicht Traefik den Request an den dafür konfigurierten Service (Container) weiter oder gibt die Antwort des besagten Dienstes aus. Der Kerngedanke meiner Überlegungen ist nun, die Pfade für die verschiedenen Aufgaben zu trennen. Die Betrachtung der Logs kann ja durchaus signifikante Aufwände erzeugen, das möchte ich nicht im performancekritischen Live-Pfad haben. Im Live-Pfad wird dann nur noch (über die ForwardAuth-Middleware) der genannte Dienst abgefragt, der fragt dann eine High-Performance-"Datenbank" wie beispielsweise Redis und gibt je nach Antwort einen entsprechenden HTTP Statuscode oder einen HTTP 403 zurück. Abgesehen davon kann ich die Analyse meiner Logs auch nicht -- oder nur unter stark erschwerten Bedingungen -- mit einem ForwardAuth-Dienst machen, denn das findet ja vor dem Request an den Backend-Service statt und daher habe ich an dieser Stelle noch gar keinen Statuscode, es sei denn, ich würde eine Liste aller zulässiger HTTP-Pfade aller Services... genau, nein. Eine weitere Idee, die mir dabei gekommen ist, ist allerdings: wenn ich mal Langeweile habe, könnte ich automatisierte Reports an die Abuse-Adressen der beteiligten ISPs schreiben. Das ist allerdings eh Zukunftsmusik, kommen wir also wieder zum Anfang zurück: der Freund-Feind-Erkennung. Hat jemand Einwände gegen meinen Ansatz, (manuell gepflegte) Scores je nach Land (GeoIP), Statistiken über die Klassen der HTTP-Responsecodes sowie die Daten von Dshield FireHOL ... zur Klassifizierung zu verwenden und die Ergebnisse aus diesen Daten zu korrelieren? Hat vielleicht jemand weitere kluge Ideen, was ich betrachten könnte oder wo es interessante Daten gibt? Lieben Dank für Eure Mitwirkung. PS: FTP gibt es auf meinen Maschinen schon seit > 20 Jahren nicht mehr. Eine schöne Anekdote aus jener Zeit ist, daß meine Webdesigner damals sehr böse geworden sind, weil ihr Macromedia Dreamweaver kein SFTP konnte. Auf meine E-Mail an Macromedia, daß SFTP eine prima Idee und höchstwahrscheinlich leicht einzubauen sei, habe ich zwar niemals eine Antwort erhalten, aber die nächste Version des Dreamweaver konnte, tadaaah!, SFTP und ich bilde mir gerne ein, daß das mit meiner E-Mail zusammenhing... :-) [1] https://doc.traefik.io/traefik/middlewares/http/forwardauth/
Hmmm schrieb: > Es gibt Hoster mit gutem Abuse-Handling, es gibt Hoster mit schlechtem > Abuse-Handling, und es gibt Bulletproof- und Fake-Hoster. Je nach > Kategorie tut oder lässt man das. Kennst Du dazu eventuell irgendwelche Daten für Provider?
Sheeva P. schrieb: > Bei den Webservern handelt es sich in meinem Fall um einen Docker Swarm > Cluster mit einem Manager- und drei Worker Nodes, auf dem Manager Node > ist Traefik als Reverse Proxy ausgerollt. Wieso sagst denn das nicht gleich?! Somit ist die Sache mit den Pipes von Hmmi wieder im Rennen, und auch der prx mit seinen (au(tomaten in den Augen spielt wieder mit. Obendrein ist wegen Reverse Proxy auch die Sache mit den durchgereichten CERTs gegessen. Deine Archillesferse liegt also - wie bei so vielen anderen - im Design. Da kann dir der Hmmi sicher weiterhelfen. Und ich dachte, du bist ein armer kleiner Webadmin. Hast du auch eigene DNS? Liebe Grüße Karl ps.: mit Proxy in front sieht die Sache gleich ganz anders aus. Vermeide doppelt gemoppelt. Kaskadiert ja, aber nicht doppelt. [a] https://www.abuseipdb.com/ [b] https://www.ripe.net/ [c] https://mxtoolbox.com/
:
Bearbeitet durch User
Hmmm schrieb: > Genau das. Auch das nicht mit den Augen, versteht sich. ;-) > Ist eigentlich recht trivial: 4xx-Errors für eine Weile cachen, bei > Überschreitung einer gewissen Anzahl pro Host und Zeiteinheit Sanktionen > (z.B. lokale Firewall-Rule) auslösen, ggf. nach einem Timeout wieder > freigeben. Hm, das wäre ein einfacher Ansatz, allerdings würde ich Verhältnisse zwischen den HTTP-Statusklassen bevorzugen, think CG-SNAT. Bei
1 | count(40x) / count(20x) |
größer 1,5 wäre, wäre das schon ein Hinweis auf einen Mistfink, bei < 0,5 würde ich das sogar als entlastendes Merkmal sehen. (Nur mal so ins Blaue, bislang habe ich noch keine Statistiken gemacht.)
Karl E. schrieb: > Also doch wieder nur die halbe Miete. Das meint, Mensch muss dann > nochmal drüber gehen, entscheiden, händisch sperren etc. > Also ich lass das die Scripts alle paar Minuten machen. Just das ist mein Punkt: ich möchte das automatisieren. Daß ich dazu erst einige Untersuchungen und Statistiken machen muß -- zum Beispiel, um die Schwellwerte zu ermitteln -- ist nicht der Punkt. > BTW. Verteilte Systeme zentral loggen lassen, alles recht und schön. Ein > kleiner Webhostbetreiber kann das nicht. hüstel Das ginge schon, wenn man denn wollte und daran interessiert wäre. Aber Logdaten lesen oder gar analysieren, das machen viele nicht, denn das kostet Zeit und Geld und Rechenleistung und... naja, am Ende eben auch eine gewisse Expertise. Und bei manchen Betreibern ist es ja auch so, daß sie... wie sage ich das jetzt... zwar mit ein bisschen Einarbeitung und Basteleien vielleicht sogar Erkenntnisse aus ihren Logs gewinnen könnten, aber was tun sie dann damit? Aus einer Mailingliste kenne ich einige Webserverbetreiber, meistens Webdesign-Einzelkämpfer oder kleine Agenturen, die haben weder die Ressourcen für solche Analysen noch die Expertise, um mit den Erkenntnissen solcher Analysen etwas sinnvolles anzufangen. Versteh' mich bitte nicht flashc: da gibt es viele sehr liebe und ihn ihren Fächern auch topfitte Experten. Aber manche von ihnen können nicht einmal dann einen Paketfilter oder einen Webserver konfigurieren, wenn ihre Hosting-Pakete das zulassen würden. Da könnte man sich als erfahrener Sysop natürlich auf den Standpunkt stellen: "wenn sie das nicht können, sollten sie keine betreiben". Aber Tatsache ist, sie tun es, und daran werden wir nichts ändern. Aus meiner ganz persönlichen Sicht wäre es deswegen klüger, ihnen zu helfen, damit dieses Internet für uns alle ein sichererer und angenehmerer Ort werden kann. Genau das ist die Überlegung, die ich gerade verfolge: am Ende will ich meine Lösung gern veröffentlichen, und sie der Allgemeinheit zur Verfügung stellen. Schon Laotse wußte allerdings, daß jeder Weg mit einem ersten Schritt beginnt. Deswegen frage ich hier: wie erkennt Ihr die Schmutzfüße, wie geht Ihr damit um, welche Maßnahmen ergreift ihr? > Vielleicht kann der TO ja a > bisschen mehr über seine Anforderungen, seine Topographie erzählen, was > die Sache besser einschätzen lässt, was vorteilhafter für ihn wäre. Das habe ich eben in einem anderen Beitrag getan und stehe für Fragen und Ideen natürlich gerne zur Verfügung. Hmmm, das wird ja doch größer (und dank Euch auch viel interessanter) als gedacht. Danke! :-)
(prx) A. K. schrieb: > Nicht zwingend. Gibt einige Open Source dazu, gerade was > Log-Konsolidierung und Darstellung angeht. Bis auf Graylog, Elastic- und OpenSearch ist mir bisher wenig Brauchbares begegnet. Hast Du bessere Ideen?
Sheeva P. schrieb: > Nur mal so ins Blaue Es gibt böse Geister, die haben viel Zeit und senden jeden Tag nur 3 Versuche und es gibt fleißige Suchmaschinen... Man sollte Erfahrung sammeln und die Quellen des Übels erkennen und sperren.
Sheeva P. schrieb: > Bis auf Graylog, Elastic- und OpenSearch ist mir bisher wenig > Brauchbares begegnet. Hast Du bessere Ideen? Ist nicht mein Bereich. Elastic ist beteiligt, aber weiter gehen meine Kenntnisse nicht.
:
Bearbeitet durch User
Karl E. schrieb: > [b] https://www.ripe.net/ Verd*mmte Axt, danke für die Erinnerung, an die RIPE-Datenbanken hatte ich noch gar nicht gedacht! :-)
:
Bearbeitet durch User
Sheeva P. schrieb: > Karl E. schrieb: >> [b] https://www.ripe.net/ > > Verd*mmte Axt, danke für die Erinnerung, an die RIPE-Datenbanken hatte > ich noch gar nicht gedacht! :-) Im Ripe ist aber nur der offizielle Besitzer der IP, de facto werden die IPs (besonders die IPv4) hin und her geschoben und vermietet. Eine gute Anlaufstelle ist https://ip-api.com/, die haben mehr oder weniger den tatsächlichen Standort des Servers, die haben auch eine schöne API, die z.B. CSV- oder JSON-Daten ausspuckt.
Sheeva P. schrieb: > Kennst Du dazu eventuell irgendwelche Daten für Provider? Du meinst Access-Provider? Leider nichts Aktuelles, weil der meiste Ärger inzwischen von "Cloud"-Hosts kommt. Die Telekom hat jedenfalls stark nachgelassen, bei den letzten Vorfällen kam nie eine Antwort. Teilweise hörten die Angriffe zwar kurz danach auf, aber ob sie eingegriffen haben oder freiwillig aufgehört wurde, blieb offen. Sheeva P. schrieb: > Hm, das wäre ein einfacher Ansatz, allerdings würde ich Verhältnisse > zwischen den HTTP-Statusklassen bevorzugen Ja, auch das wäre eine Möglichkeit. So hast Du weniger Kollateralschäden, aber wenn ein Bot erst den Content nach eMail-Adressen durchforstet, bevor er mit WordPress-Exploitversuchen o.dgl. loslegt, hat er natürlich erstmal ein paar Freischüsse. Für die eigentlichen Anwendungen (insbesondere die Logins dazu) bieten sich auch noch RBLs an. Aber auch wirklich nur dort, weil Du sonst viel DNS-Traffic erzeugst und Deine Webserver ausbremst. An solchen Stellen gibt's dann auch nicht nur schwarz und weiss, sondern auch noch die Möglichkeit, auffällige Hosts zwar zuzulassen, aber nur mit einem Captcha.
Wenn man in eine Pipe logt, ist man spaeter erst am reagieren. Wenn man direkt analysiert kann man direkt reagieren. Loggen ist sicher angesagt um spaeter analysieren zu koennen. Aber einen Systemschutz gibt es nur mit direktem analysieren. Bei SSL kommt die URL und die GET Parameter im Klartext, allfaellige POST parameter sind verschluesselt. Die Frage ist nun, will man lausige Serversoftware schuetzen, oder nur den Server gegen ueberlast und Hackversuche. Hat man die Serversoftware unter Kontrolle, oder laeuft ein loechriges Packet wie Wordpress
Pandur S. schrieb: > Wenn man in eine Pipe logt, ist man spaeter erst am reagieren. Du weisst, was eine Pipe ist? Da landet die Zeile nicht im Logfile, sondern direkt bei der Software am anderen Ende der Pipe. Dass es nicht darum geht, den jeweiligen Request abzufangen, sondern nach mehreren (!) verdächtigen Requests zu reagieren, hättest Du dem Thread entnehmen können. Pandur S. schrieb: > Bei SSL kommt die URL und die GET Parameter im Klartext, allfaellige > POST parameter sind verschluesselt. Blödsinn. Bei HTTPS ist die gesamte HTTP-Kommunikation TLS-verschlüsselt. Was zusätzlich (!) auch im Klartext übertragen wird, nämlich beim TLS-Handshake, ist der nackte Hostname bei Verwendung von SNI.
:
Bearbeitet durch User
Beitrag #7783970 wurde vom Autor gelöscht.
Hmmm schrieb: > Pandur S. schrieb: >> Bei SSL kommt die URL und die GET Parameter im Klartext, allfaellige >> POST parameter sind verschluesselt. > > Blödsinn. Bei HTTPS ist die gesamte HTTP-Kommunikation > TLS-verschlüsselt. Was zusätzlich (!) auch im Klartext übertragen wird, > nämlich beim TLS-Handshake, ist der nackte Hostname bei Verwendung von > SNI. Korrekt. Siehe https://datatracker.ietf.org/doc/html/rfc2818 bzw. https://www.datenschutzzentrum.de/tb/tb37/kap10.html [Zitat] Vorsicht bei der Einführung von TLS 1.3 ist allerdings angesagt, denn mit TLS 1.3e bzw. eTLS oder (nach Intervention der IETF ob des Namens) nun ETS wurde an der IETF vorbei unter einer sehr ähnlichen Bezeichnung eine künstlich kompromittierte Variante von TLS 1.3 publiziert, die einige der neuen Sicherheitsfeatures wieder untergräbt und damit deutlich hinter den Stand der Technik zurückfällt: [/Zitat] Wer verwendet das durch die EU reingedrückte eTLS? Anbei eine genaue Beschreibung von damals vor Einfürung durch die EU. Liebe Grüße Karl
:
Bearbeitet durch User
Sheeva P. schrieb: > Bis auf Graylog, Elastic- und OpenSearch ist mir bisher wenig > Brauchbares begegnet. Hast Du bessere Ideen? Habe grad gefragt: Elastic + Kibana als Kernprodukte. Dann gibt es eine Reihe Log-Anlieferer wie Logbeat für Windows, Linux, Syslog, Firewalls, ... Erst für sowas wie KI gestützte Auswertung wird Geld fällig.
:
Bearbeitet durch User
> > Pandur S. schrieb: >> Bei SSL kommt die URL und die GET Parameter im Klartext, allfaellige >> POST parameter sind verschluesselt. > > Blödsinn. Bei HTTPS ist die gesamte HTTP-Kommunikation > TLS-verschlüsselt. Was zusätzlich (!) auch im Klartext übertragen wird, > nämlich beim TLS-Handshake, ist der nackte Hostname bei Verwendung von > SNI. Nicht alle koennen alles verstehen... Wie soll eine URL bei einem Router aufgeloest werden wenn sie verschluesselt ist ? Was soll denn Vorratsgespeichert werden wenn's denn verschluesselt ist ?
Pandur S. schrieb: > Nicht alle koennen alles verstehen... Wie soll eine URL bei einem Router > aufgeloest werden wenn sie verschluesselt ist ? Ein Router interessiert sich für IP-Adressen, nicht für URLs. Egal ob verschlüsselt oder nicht.
:
Bearbeitet durch User
Pandur S. schrieb: > Was soll denn Vorratsgespeichert werden Die Zuordnung von IP Adressen zu Haushalten.
Pandur S. schrieb: > Nicht alle koennen alles verstehen... Wie soll eine URL bei einem Router > aufgeloest werden wenn sie verschluesselt ist ? Wenn 50 verschiedene Seiten unter 50 verschiedenen Servernamen auf 1 Server liegen, haben die Seiten alle die gleiche IP-Adresse. Dieser Server erhält von Client per SNI unverschlüsselt ausschliesslich den Servernamen aus der URL, damit er das richtige Zertifikat zuordnen kann. Erst dann kann anhand dieses Zertifikats die TLS-Verbindung aufgebaut werden und die Seite wird darüber ansprechbar.
:
Bearbeitet durch User
Pandur S. schrieb: > Nicht alle koennen alles verstehen... Wie soll eine URL bei einem Router > aufgeloest werden wenn sie verschluesselt ist ? Deshalb gibt es die RFCs. Warum liest Du sie einfach nicht mal, wenn ich dir sogar den Link poste? Liebe Grüße Karl
(prx) A. K. schrieb: > Pandur S. schrieb: >> Was soll denn Vorratsgespeichert werden > > Die Zuordnung von IP Adressen zu Haushalten. Und noch viel mehr! Wäre bereits IPv6 vollends implementiert, würde sogar jedes Haar - inklusive jede einzelne Amöbe - auf deinem Körper eindeutig addressierbar sein. Und da du durch eine eindeutige IPv6-Adresse dann vollständig gläsern bist, auch wenn du bloß atmest, all das weiß das Netz dann bzw. all jene, die dich kontrollieren wollen. Gute Nacht! Liebe Grüße Karl
Karl E. schrieb: >> Die Zuordnung von IP Adressen zu Haushalten. > > Und noch viel mehr! > Wäre bereits IPv6 vollends implementiert, würde sogar jedes Haar - > inklusive jede einzelne Amöbe - auf deinem Körper eindeutig > addressierbar sein. Dafür gibt es die IPv6 Privacy Extensions. Karl E. schrieb: > Und da du durch eine eindeutige IPv6-Adresse Üblicherweise wird bei Privatkunden der Prefix (analog zu IPv4-Adressen) dynamisch zugeteilt, und die Host-Adresse wechselt dank Privacy Extensions ebenfalls. Ohne hättest Du natürlich recht, wenn jeder seine MAC-Adresse in die Welt posaunen würde.
Pandur S. schrieb: > Nicht alle koennen alles verstehen... Richtig. Vielleicht siehst du dir das mal an: https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_%E2%80%93_Vermittlungsschicht_(Network_Layer) Routing geschieht am Layer3. Der weiß nichts, was in der Payload steckt. Die Auflösung der IP-Adressen ist etwas ganz anderes, als die Auflösung einer URL. Ich kenne welche, die glauben tatsächlich, dass sie auf Webseiten surfen, sozusagen phsikalisch dort Vorort sind. Wenn du eine Website dir anschaust, dann ist sie auf deinem Computer. Liebe Grüße Karl
Hmmm schrieb: > Üblicherweise wird bei Privatkunden der Prefix (analog zu IPv4-Adressen) > dynamisch zugeteilt, und die Host-Adresse wechselt dank Privacy > Extensions ebenfalls. Alles klar. Nur das ist nicht in Stein gemeisselt. Liebe Grüße Karl
Beitrag #7784278 wurde vom Autor gelöscht.
(prx) A. K. schrieb: > Habe grad gefragt: Elastic + Kibana als Kernprodukte. Dann gibt es eine > Reihe Log-Anlieferer wie Logbeat für Windows, Linux, Syslog, Firewalls, > ... Erst für sowas wie KI gestützte Auswertung wird Geld fällig. Also der klassische ELK-Stack, der ist IMHO immer eine gute Wahl. Danke, daß Du das nochmal nachgefragt hast! :-)
Karl E. schrieb: > Ich kenne welche, die glauben tatsächlich, dass sie auf Webseiten > surfen, sozusagen phsikalisch dort Vorort sind. Wenn du eine Website dir > anschaust, dann ist sie auf deinem Computer. Und was ist daran falsch, wenn wir vereinfachend von statischem HTML ausgehen? Da befindet sich die gerade dargestellte Seite tatsächlich als Kopie auf deinem Computer. Von solcher Sophisterei leben DRM-Anwälte und andere aus der Rechthaber-Branche.
:
Bearbeitet durch User
Beitrag #7784609 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > Hallo, > > hier im Forum gibt es Menschen, die -- wie auch ich -- einen oder > mehrere öffentliche Webserver betreiben und deren Logdate(i)en dabei von > allerlei "besonderen Menschen" überflutet werden. > > Meine Fragen ist: tut Ihr etwas dagegen? Wenn ja, was? > > Lieben Dank, > Sheeva Ich blocke einfach alle Zugriffe von nicht deutschen IPs und TOR Exitnodes aus.
Tim T. schrieb: > Ich blocke einfach alle Zugriffe von nicht deutschen IPs und TOR > Exitnodes aus. Hier gilt die Unschuldsvermutung nicht, lieber ein paar Unschuldige ausgesperrt als die vielen Schuldigen reinzulassen. ..oder war es umgekehrt? ;-))) MfG alterknacker
Beitrag #7784766 wurde vom Autor gelöscht.
Beitrag #7784779 wurde von einem Moderator gelöscht.
Tim T. schrieb: > Ich blocke einfach alle Zugriffe von nicht deutschen IPs und TOR > Exitnodes aus. Puh... das wäre einfach, geht hier aber leider nicht. :-)
Al. K. schrieb: > Hier gilt die Unschuldsvermutung nicht, Auch Dich möchte ich bitten, diesen Thread zu verschonen, solange Du nichts Konstruktives zu seinem Thema beitragen kannst. Vielen Dank.
(prx) A. K. schrieb: > Und was ist daran falsch, wenn wir vereinfachend von statischem HTML > ausgehen? Alles! Erstens bitte lese genau, was ich geschrieben habe. Zweitens was hat HTML (Markuplanguage) mit HTTP(S) (Layer7) zu tun? > Da befindet sich die gerade dargestellte Seite tatsächlich als > Kopie auf deinem Computer. Nicht nur da. Lese https://datatracker.ietf.org/doc/html/rfc2616 und schau dir das OSI-Modell einmal an. Und danach lies selbst noch einmal dein Posting. > Von solcher Sophisterei leben DRM-Anwälte und andere aus der > Rechthaber-Branche. Bleib am Teppich. Liebe Grüße Karl
:
Bearbeitet durch User
Karl E. schrieb: > Nicht nur da. Lese https://datatracker.ietf.org/doc/html/rfc2616 und > schau dir das OSI-Modell einmal an. Und danach lies selbst noch einmal > dein Posting. Auch ohne erneute Lektüre von RFCs ist es für meine Fragen und diesen Thread unerheblich. Wenn Du das detaillierter ausdiskutieren möchtest, dann eröffne bitte einen eigenen Thread dazu. Vielen Dank.
Beitrag #7784923 wurde von einem Moderator gelöscht.
Beitrag #7784929 wurde von einem Moderator gelöscht.
Beitrag #7784970 wurde von einem Moderator gelöscht.
Beitrag #7784972 wurde von einem Moderator gelöscht.
Beitrag #7784976 wurde von einem Moderator gelöscht.
Beitrag #7785003 wurde von einem Moderator gelöscht.
Beitrag #7785012 wurde von einem Moderator gelöscht.
Beitrag #7785035 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > Auch ohne erneute Lektüre von RFCs ist es für meine Fragen und diesen > Thread unerheblich. Das ist ein Irrtum. Ein schwerer Fehler. Denn versteht man, wie Protokolle funktionieren, kann man Gegenmaßnahmen ergreifen, um Attacken abwehren, abschwächen, umlenken und und und zu können, was ja dein Begehr ist. Und offensichtlich hast - und nicht nur du - genau dort das Problem. »Wasch mir den Pelz, aber mach mich nicht naß« ;-) Sehr gerne werde ich mit Expertise und Wortspenden auf dein Ersuchen hin von nun an Abstand nehmen. Liebe Grüße Karl
Gerade mal wieder spaßenshalber meine Logdatei durchgelesen... Reiner Testserver ohne Domain an privater IP, also könnte man praktisch jeden Zugriff von extern, der nicht durch mich selbst oder Bekannte von mir erfolgt, als potentiellen Angriff werten. Ansonsten halt die üblichen Scans nach "kaputter" Software in ihren Standard-Pfaden, die üblichen Versuche von directory traversals, code injection... jede Menge traurige 400 und 404 Fehler. Lustigerweise kein einziger Zugriff auf Dinge, die wirklich auf dem Server liegen. Gut, erstes kleines Foul, die Pfade sind nirgendwo gelistet und /index enthält nur eine komplett leere und funktionslose Seite. Aber ich kriege Lust, mir mal anzuschauen, was da teilweise bei den versuchten code injections base64-codiert verschickt wurde. Oder vielleicht ist genau das die Falle, wer weiß. Wenn ich da jetzt versuche, zu jeder der geloggten IPs den ISP oder Hoster zu ermitteln und abuse-eMails zu verschicken, dann wäre ich wahrscheinlich die ganze Nacht beschäftigt. Nee, da habe ich besseres zu tun. Wenn solche Angriffe nicht üblicherweise deutlich mehr Bandbreite hätten als ich, würde ich denen am liebsten auf manche Anfragen hin erstmal 100 Megabyte zufälligen Datenmüll zurückschicken, der sich extra schlecht komprimieren lässt...
:
Bearbeitet durch User
Ben B. schrieb: > würde ich denen am liebsten auf manche Anfragen hin erstmal 100 > Megabyte zufälligen Datenmüll zurückschicken, der sich extra schlecht > komprimieren lässt... Leg doch mal ein Verzeichnis mit einer alten Linux-CD an und verschlüssle diese. Du wirst interessante Logs finden. Hat mein Dozent schon vor Jahren gemacht.
Ben B. schrieb: > Wenn ich da jetzt versuche, zu jeder der geloggten IPs den ISP oder > Hoster zu ermitteln kann man automatisieren, z.B. mit der API von https://ip-api.com/ > abuse-eMails zu verschicken ist sinnlos > dann wäre ich wahrscheinlich die ganze Nacht beschäftigt. dauert hier für 3 Server ca 15-20 Minuten
Beitrag #7790585 wurde vom Autor gelöscht.
Beitrag #7790586 wurde vom Autor gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.