Telex aus China

[BjoernS]

Hallo zusammen,

ich würde gerne eure Erfahrungen/Meinungen einholen zu einem Thema, das sich grob zusammenfassen lässt als "Telex-SPAM".

Bisher war die Anzahl der Nachrichten eher gering, aber letztens hatte ich nachts neun solcher Verbindungen kurz hintereinander. piTelex archiviert mir ja alles schön ordentlich, deshalb siehe unten für die gesammelten Werke.

Ich würde diesen Thread gerne dazu nutzen, eure Erfahrungen zu sammeln, so dass man ggf. Gegenmaßnahmen etablieren kann, falls das Problem weiter wächst.

Allen Vorfällen ist gemein, dass sie über das ASCII-Protokoll zustande kommen. Vermutlich verbindet sich jemand ahnungslos mit dem Telex-Port und erwartet dort einen anderen Dienst. Das ist an sich erstmal kein Problem, kann aber bei wiederholten Versuchen nerven. Mit bösem Willen wäre recht einfach mehr anzurichten (Papierrolle leerdrucken zum Beispiel).

Als mögliche Gegenmaßnahmen fallen mir ein:

1. ASCII-Protokoll eingehend deaktivieren -- wo wird dies in der i-Telex-Landschaft noch genutzt?
2. GeoIP-Filter: Eingehende Verbindungen nur aus "vertrauten" Herkunftsländern zulassen. Einfach für piTelex, wahrscheinlich schwer umzusetzen für i-Telex.
3. Stattdessen könnte man sich eine serverbasierte Filtermöglichkeit überlegen, bei der der TNS mitarbeitet, z.B.: Prüfe bei eingehender Verbindung, ob IP-Adresse im TNS als gültiger Anschluss hinterlegt ist. Wäre aber ein größerer Umbau und vmtl. langwierig in die Breite auszurollen.
4. Häufigkeitsfilter: Per eingehender Adresse eine Sperrzeit aktivieren, die sich bei Wiederholung exponentiell vervielfacht -- hilft gegen viele kurze Verbindungsversuche
5. Zeitdauerfilter: Nach x min Verbindung kappen -- hilft gegen "Besetzt-SPAM"
6. Längenfilter: Nach x Zeichen Verbindung kappen -- hilft gegen "Papier-SPAM"

Was sind eure Erfahrungen und/oder Meinungen?

Grüße


Björn

Verstecken ist aktiviert

Um diesen versteckten Text lesen zu können, musst du registriert und angemeldet sein.

[Fernschreiber]

:llach: Hallo Björn,

hier mal meine Gedanken zumThema.
Wie bekannt sein dürfte, habe ich in meiner Pi-Lösung immer den ASCII-Service nach aussen aus verschiedensten Gründen immer vermieden. Daher ist das Problem bei mir nicht so vordringlich. Aber es gibt in der Tat TCP-Connects, die nicht sinnvoll sind, aber für eine Zeit den Port belegen. Nun, davon geht die Welt in einem Hobbysystem auch nicht unter. Da ich nur Zeichen < 33 zulasse und zu Beginn definitiv die Versionsaushandlung erzwinge, passiert ausser der Belegung nichts und nach 5-10 Sekunden wird ausgelöst. Auch der evt. intensive Verkehr mit dem Gegenüber mittels nicht darstellbaren bzw. Steuer-Zeichen dürfte die Gegenseite verwirren. Dieses System funktioniert auf der KLKL-Serverplattform (kein ASCII) auch sehr gut; gleichwohl hat mir Thomas mal mittgeteilt das solche Connects auch dort auftauchen. Er versucht das in der Firewall zu unterdrücken.
Um diesen Effekt zu minimieren wäre Dein Punkt 1 für i-Telex zu favorisieren. Ich weiß aber nicht ob das jetzt schon mit einem Häckchen abgehend geht. Ganz abschalten würde mindestens den Wetterdienst betreffen.
Da wir mittlerweile ein internationales Grüppchen sind, wird Dein Punkt 2 schwierig, ausserden müsste eine aktuelle verlässliche Liste mit den länderspezifischen IP-Adressen vorgehalten werden. Was passiert wenn ein Chinese hier mitmachen möchte. Auch wenn das mit einer Serverabfrage bei Anruf erfolgen könnte ist der Updateaufwand ,wie Du schon schriebst ,groß.
Dein Punkt 3 habe ich mir auch schon für die Sereverplattform überlegt, habe dann aus zwei Gründen erstmal gestoppt.
Einerseits werden dann evt. Verbindungen unterbunden, weil das DNS (intern auf i-Telex Server bzw. das Internet-DNS) immer zeitverzögert aktualisiert wird. Dann sucht man einen Fehler, der plötzlich verschwindet und niemand weiss warum.
Andererseits sind all die Central-EX Nutzer nur mit der (gleichen) Eingangs-IP im Server hinterlegt. Wenn Diese eine ausgehende Verbindung aufbauen, dürfte das mit der lokalen unbekannten IP geschehen. Sollte das nicht so sein (würde mich aus Performancegründen aber wundern) und der ausgehende Verkehr nutzt die IP auch, wäre die IP-Filterung durchaus praktikabel. Sonst keine Chance zu filtern, es sei denn auch die lokale IP wird im Server wie sonst auch zusätzlich hinterlegt. Ist aber Aufwand und bedeutet Ändern des Protokollinhalts bei Serverabfrage und damit grössflächige Updateaktion.

Deine Punkte 4-6 sind natürlich eine Möglichkeit der Abwehr. Damit hat man aber wieder 3 Punkte mehr im Menue, die jeder für sich entscheiden und mit Parametern füllen muss. Alle drei Punkte sind extremst diskutabel, erforden neue SW und Update. Da würde ich bei einem i-Telexsystem Deinen Punkt 1 als die Version bevorzugen, die mit einem Update auskommt und nur einen eindeutigen Haken mehr haben dürfte. I-Telex untereinander sprechen sowieso beide Sprachen, die Erreichbarkeit bleibt erhalten, die PI-Versionen sollten mittlerweile (hoffentlich) auch auf dem Baudot-Prinzip basieren. Gegen einlaufende TCP-Connects wie auch immer ist man naturgemäss machtlos, man kann sie nur nach Logik schnellstens beenden.

Eine weitere Lösung wäre ein vorgeschalteter kleiner Rechner, der den Connect erstmal annimmt und nur bei erfolgreicher logisch sinnvoller Kontaktaufnahme transparent zum Endsystem durchschaltet (Prinzip Firewall) oder beendet. Er muß sich dem lokalen System dann aber als echte Gegenstelle darstellen und definitiv den Anrufvorgang des Anrufers simulieren (nachholen). Das hätte den Vorteil, das die vermutlich wenigen Betroffenen am System nichts machen müssen und Updateaktionen im großen Stil ausbleiben können. Muß nur jemand bauen.

Mehr fällt mir dazu im Moment nicht ein, bin aber mal gespannt ob noch andere mögliche Szenarien von Mitstreitern abgeboten werden. Interessant ist das Thema allemal, zumal dadurch ein kleiner Überblick zusammenkomm oder bei welcher Zahl die Betroffenen (die es bemerken) überhaupt liegen.
Ich kann mit meiner Lösung "Baudotprotokoll inkl. Versionsaushandlung oder nichts" sehr gut leben, die Server bei Thomas auch.

Gruß
Willi

[roliw]

Hallo Björn
Ich hatte diese Probleme täglich von einem Russischen Störenfried. Zumindest löste er
nach einem Angriff eine Fehlermeldung von iTelex aus. Ich habe den Adressbereich des
Russischen Providers in meinem Firewall gesperrt und habe seither Ruhe.
Klar ist das keine elegante Lösung. Zu bevorzugen wäre eine beidseitige Identifikation.
Aber für den Moment bin ich recht glücklich damit.
Beste Grüsse
Roland

[FredSonnenrein]

Hallo zusammen,
zunächst meine Erfahrung: Bisher hatte ich nur "Angriffe" per versuchten HTTP-Zugriff. Dies ist mit der neuen Firmware der Ethernet-Karte "im Griff".
Vielleicht "hilft" es, dass ich eine wechselnde IP habe. Offensichtlich konzentrieren sich die Angreifer auf Anschlüsse mit fester IP-Adresse.

Abhilfen:
Neben den genannten Möglichkeiten sehe ich noch eine kleine weitere Filtermethode: Im i-Telex-Ascii-Protokoll ist ja die Durchwahl per *12* implementiert. Man könnte auf diese Kombination filtern und alle anderen Verbindungen ablehnen.
Franks Wetterserver verwendet immer diesen Durchwahl-Code. "Nur" Klaus "einfaches Interface" müsste ggf. geringfügig angepasst werden.

[kerk1v]

Hallo,

Die piTelexer könnten evtl. https://www.fail2ban.org/wiki/index.php/Main_Page benutzen. Man bräuchte zwar ein Logfile in dem die IP-Addressen eingehender Verbindungen hinterlegt sind. Dann Fail2ban derart einstellen dass nach x versuchen innerhalb von n Minuten von der selben IP diese IP-Addresse für z Minuten blockiert ist. Die meisten Portscanner sehen dann von weiteren Versuchen ab, weil sie denken, die IP ist nicht erreichbar.