(Port)Scans bei Centralex-Anbindung?

[ISBRAND]

Also dringenden Handlungsbedarf sehe ich jetzt auch nicht. ASCI II ist bei mir auch aus und Firmenware ist frisch. Es ist immer nur ärgerlich, du freust dich, da hat jemand dir ein Telex geschickt und dann siehste den Müll auf dem Rollenpapier
So lange ich den T 100s auf der 31195 hatte, war die Nachtschaltung aktiv zu einem LO 3000, damit meine Nachbarn nicht geärgert werden hier im Neubaublock , wenn mitten in der Nacht so ein Scan ablief.

[detlef]

ASCI II ist bei mir auch aus und Firmenware ist frisch.

Und immer noch Scans? Poste doch bitte nochmal ein Foto von dem Ausdruck, wenn das wieder passiert.

[ISBRAND]

Nein jetzt hatte ich länger nix, vielleicht ist ja die eine oder andere Angriffswelle vorbei.
ASCI II abschalten hatte da mals schon viel gebracht, aber zur Zeit ist Ruhe, 3 x auf Holz geklopft.

[obrecht]

Bei piTelex gab's auch immer dieses Probleme, zumal Centralex (noch) nicht unterstützt wird. Aber seit der Einführung der Option "block_ascii", die nur ankommende ASCII Verbindungsversuche unterdrückt und die in der aktuellen Release nochmal verbessert wurde, ist bei mir seit Monaten auch absolute Ruhe im Karton.

[duddsig]

Also du hattest definitiv noch Portscan-Ausdrucke trotz abgeschaltetem ASCII? Das ist mir technisch völlig unverständlich, wie das funktionieren kann.
Der Scanner müsste sich dann an das i-Telex-Protokoll halten und die Daten im ITA2-Code senden.

So ist es, fast ein Jahr lang. Firmware ist übrigens aktuell.
Einzig die Scans mit den vielen ZZZZZ (siehe Bild von Isbrand) sind verschwunden. War bei mir ungefähr ein drittel der Gesamtmenge

Die Probleme mit der Geheimzahl sind auch unabhängig von Portscans aufgetreten. Vor allem gehäuft im Frühjahr diesen Jahres. Ich weiß von einigen, die davon betroffen waren. Aber seitdem habe ich nichts mehr gehört. Wenn jemand dieses Problem mit der angeblich falschen Gehimzahl hat, dann unbedingt Bescheid sagen, damit wir der Sache nochmal nachgehen können.

Ich denke, daß das definitiv auch mit Scans zusammenhängt, vor allem, wenn wie Du schreibst andere auch davon betroffen waren und jetzt nicht mehr.
Kann ja nicht sein, daß zeitlich begrenzt auf einmal einzelne Syteme unabhängig von einander das gleiche Fehlverhalten aufweisen. Egal ob Centralex oder nicht.

Wie bereits geschrieben, ist seit einem Monat Ruhe und das System läuft jetzt wieder durch. Einzig die Sache mit der Geheimzahl WAR schlecht, weil die Kiste dadurch dauerhaft vom Netz war, und das alle 2 Tage. Ist nun aber auch mit wech....

[detlef]

Firmware ist übrigens aktuell.

Bei einem Testanruf auf der 7977457 wurde mir die Version 915 gemeldet. Aktuell ist 966.

Kann ja nicht sein, daß zeitlich begrenzt auf einmal einzelne Syteme unabhängig von einander das gleiche Fehlverhalten aufweisen. Egal ob Centralex oder nicht.

Das kann schon sein, wenn das Problem beim Server liegt.

[detlef]

Ich habe hier noch was in der Versionshistorie gefunden:

Ab Build 965:
Fehler bei Nicht-Sommerzeit und negativen Zeitzonen behoben.
Verändertes Verhalten der lokalen Teilnehmerliste
Verbesserung bei "Port-Scans" und "Langen Dienstmeldungen"

Es gab also ab Version 965 noch mal irgendeine Verbesserung bei der Behandlung von Port-Scans.

[duddsig]

Bei einem Testanruf auf der 7977457 wurde mir die Version 915 gemeldet. Aktuell ist 966.

Huch, ich meinte ich wäre aktuell.
Na wenigstens hat der Testanruf geklappt , vor einem Monat wäre das nicht so sicher gewesen.

Das kann schon sein, wenn das Problem beim Server liegt.

Das klingt erst mal plausibel.
Hat sich denn da exakt vor einem Monat was geändert?
Im speziellen habe ich 3x tlnserv2.teleprinter.net eingetragen, das war Fred's letzter und für mich aktueller Hinweis, da wohl an den Servern gebastelt wurde.
Sind den inzwischen alle 3 Server Centralex-fähig? Soll ich wieder 1 und 3 mit includieren?

[detlef]

Hat sich denn da exakt vor einem Monat was geändert?
Sind den inzwischen alle 3 Server Centralex-fähig? Soll ich wieder 1 und 3 mit includieren?

Konkret geändert wurde meines Wissens nichts, aber der Centralex-Server scheint wohl ab und zu Probleme zu haben. Ich hatte es in den letzten Monaten zweimal, dass der Haken "Standverbindung zum Server wegen nicht-öffentlicher IP verwenden" draussen war. Das macht wohl die Netzwerkkarte selbstständig, wenn sie Centralex nicht erreichen kann.

Es gab natürlich Änderungen durch den Umzug auf einen anderen Server. Das lässt sich aber Einzelfall schwer nachvollziehen, ob es dadurch Probleme gab.

Centralex läuft nach wie vor nur auf dem tlnserv2. Du kannst deine Einstellungen so lassen.

[detlef]

Und dann ist es mir gestern gelungen, den Passwort-Fehler unabsichtlich zu provozieren.

Centralex-Fehler 241209.jpg

Aber ich habe jetzt eine Idee, was da möglicherweise passiert.

Ich hatte an meinem i-Telex rumgeschraubt um ein dauerhaftes Logging der i-Telex-Karte zu realsieren. Die Karte läuft testweise mit Centralex (Nummer 211231). Um das Logging zu testen, habe ich mit WinTlx eine Verbindung zur 211231 aufgebaut und dann versehentlich das i-Telex ausgeschaltet ohne die Verbindung zu beenden.

Dann ist folgendes passiert: Die Verbindung zum i-Telex war natürlich weg, aber die Verbindung von Centralex zu WinTlx bliebt bestehen.
Und ich konnte keine neue Verbindung zur 211231 aufbauen. Centralex meldete "occ".

Nach einige Minuten kam dann die Meldung mit dem falschen Passwort. Das wurde vermutlich dadurch ausgelöst, dass mein i-Telex sich nicht neu mit Centralex verbinden konnte, weil der Anschluss ja belegt war. Wie man an der Meldung unten sieht ("dynamische ip aktualisierung und remote-server anbindung abgeschaltet"), wird dann dummerweise die Konfiguration der i-Telex-Karte geändert und jegliche Serverupdates unterbunden. Ab diesem Zeitpunkt funktionieren ohne händischen Eingriff überhaupt keine eingehenden Verbindungen mehr.

Warum Centralex einen Passwortfehler meldet oder das i-Telex meint, dass da ein Passwortfehler vorliegt, dass ist mir noch nicht klar. Das könnte ein Softwarefehler auf dem Centralexserver oder in der i-Telex-Firmware sein.

Die Verbindung zwischen Centralex und WinTlx wurde dann übrigens nach ca. 10 Minuten automatisch beendet. Es gibt wohl ein Inaktivtäts-Timeout. Der Centralex-Server ist dann wieder bereit und könnte wieder eine Verbindung annehmen. Aber dann ist es schon zu spät. Das i-Telex-System hat dann die Remote-Server-Einstellung schon gelöscht.

Prinzipiell ist es ja sinnvoll, dass das i-Telex die Server-Aktualisierung einstellt, wenn ein Passwortfehler erkannt wird. Um die Server nicht unnötig zu belasten. Die Frage ist jetzt, warum kommt der Passwortfehler.

Ich werde nochmal ein paar Tests machen.