COMport-Server immer über WAN erreichbar!

[Rougu]

Hi,

der COMport-Server ist eine feine Sache, um Linux-Server oder Telefonanlagen oder, oder, oder auch dann noch zu "retten", wenn sie vom Netz abgehängt sind. Ich nutze das Feature gerne über VPN oder im Intranet.

ABER HEUTE ÜBERFIEL MICH DER GRUSEL, als ich im Webinterface die Dienstetabelle anschaute.
Der COMport-Server hängt offen am WAN, und es ist eine ungesicherte Telnet-Schnittstelle.

Offensichtlich war das schon immer so, ich habe sofort mit einem alten LCOS 8.84 getestet.

Ich habe keine Möglichkeit gefunden, das abzustellen:
- in den Zugriffseinstellungen kommt der Comport-Server nicht vor
- Firewallregeln greifen nicht, weil interne Dienste nicht über die Firewall laufen.
- Im Einstellmenü für den Comport-Server ist zwar die Schnittstelle einstellbar, über die die Pakete verschickt werden, aber wenn dort "INTRANET" steht, heisst es eben nicht, dass nur er nur aus dem erreichbar ist.

Gerettet haben mich wohl bisher nur Port-Obscurity und ordentliche Passwörter....

Aber schön wäre es trotzdem, wenn Berufene diesen Angriffsweg abdichten würden und den Comport-Server in das Admin-Menü "Zugriffseinstellungen" aufnehmen würden. Oder habe ich was übersehen?

Gruß,

rougu

[alf29]

Guten Abend,

ABER HEUTE ÜBERFIEL MICH DER GRUSEL,

Wer den Entwickler anbrüllt, riskiert ignoriert zu werden. Entwickler sind nämlich auch nur Menschen, und Dinge laufen manchmal halt nicht so wie sie idealerweise sollten. Dafür dann die Prügel einzustecken hat nicht jeder Lust.

Der COMport-Server hängt offen am WAN,

Tja, als der geschrieben wurde, hieß es demnächst kommt die neue Firewall, und die hat dann auch Inbound-Filter (so wie IPv6 von Anfang an). Das war vor mindestens fünf Jahren, und wir sind immer noch an dem Punkt, daß jeder LCOS-interne Dienst für IPv4 seine eigenen 'über WAN ja/nein/nur-VPN'-Schalter einbauen darf Worauf es dann wohl herauslaufen wird, wenn morgen der zu erwartende 'wie konnte das nur passieren' Sturm losbricht.

Ich denke, die Mehrzahl der Nutzer dec COM-Port-Servers (das sind a priori nicht so viele) nutzt ihn nicht auf dem Internet-Gateway selber, sondern z.B. auf irgendeinem AP intern. Dessen COM-Port-Server-Port wäre vom Internet nur zu erreichen, wenn es auf dem maskierenden Gateway irgendeinen Eintrag dafür gäbe.

und es ist eine ungesicherte Telnet-Schnittstelle.

Telnet per se hat prinzipiell keine Authentisierungsmechanismen. Ein Telnet-Client und -Server stellen bloß eine TCP-Verbindung her und handeln vielleicht noch ein paar Optionen für lokales Echo und CR/LF-Umwandlung aus. Wenn bei einer Telnet-Verbindung ein Login-Prompt kommt, dann kommt der weder vom Telnet-Client noch vom -Server, sondern vom Login-Daemon auf dem entfernten System.

Daß man auf einen vom COM-Port-Server bereitgestellten Port ohne irgendwelche Authentisierung draufkommt, muß im Gegensteil so sein - sonst würden diverse virtuelle COM-Port-Treiber nicht funktionieren, die zum Betrieb mit diesem Server gedacht sind.

- Firewallregeln greifen nicht, weil interne Dienste nicht über die Firewall laufen.

Korrekt, für IPv4 leider (noch) nicht.

- Im Einstellmenü für den Comport-Server ist zwar die Schnittstelle einstellbar, über die die Pakete verschickt werden, aber wenn dort "INTRANET" steht, heisst es eben nicht, dass nur er nur aus dem erreichbar ist.

Das bezieht sich nur auf ausgehende Verbindungen, wenn der COM-Port-Server selber die TCP-Verbindung zu einem entfernten Host aufbaut. Damit legt man fest, mit welcher lokalen Adresse die Verbindung aufgebaut wird.

Aber schön wäre es trotzdem, wenn Berufene diesen Angriffsweg abdichten würden und den Comport-Server in das Admin-Menü "Zugriffseinstellungen" aufnehmen würden.

Da gehört so ein Schalter m.E. nicht hin, weil (1) der COM-Port-Server kein Zugangsweg zur Administrierung des LANCOM selber ist und (2) der COM-Port-Server selber mehrere Instanzen solcher Verbindungen unterhalten kann und man das für unterschiedliche Instanzen möglicherweise unterschiedlich haben will. Eine Spalte in der Art 'WAN-Zugang ja/nein/nur-VPN' in den Netzwerkeinstellungen wäre m.E. der korrekte Ort.

Oder habe ich was übersehen?

Nein, hast Du nicht. Postings in diesem Ton führen aber dazu, daß am nächsten Tag ein panischer PM die Weisung ausgibt, der WAN-Zugriff sollte doch bitte komplett und ohne Einstellmöglichkeit abgeklemmt werden. Und wie 'glücklich' dann potentiell andere Kunden über so eine Kurzschlußreaktion sind, kann man hier im Forum am SIP nachlesen...

Gruß Alfred

[cpuprofi]

...Postings in diesem Ton führen aber dazu, daß am nächsten Tag ein panischer PM die Weisung ausgibt, der WAN-Zugriff sollte doch bitte komplett und ohne Einstellmöglichkeit abgeklemmt werden. Und wie 'glücklich' dann potentiell andere Kunden über so eine Kurzschlußreaktion sind, kann man hier im Forum am SIP nachlesen...

Alfred, damit sprichst Du mir aus der Seele...

Grüße
Cpuprofi

[Christoph_vW]

Wo wir gerade beim Thema COMport Server sind - bitte eine Möglichkeit zum "Neustart" im LANmonitor einbauen.
Ich habe immer wieder das Problem das einige Verbindungen hängen und man entweder den ganzen Router neu starten muss, oder COMport Server aus- und wieder einschalten muss. -> nervig.

[alf29]

Ich habe ehrlich gesagt keine Ahnung, was ich da "neustarten" sollte?

[Christoph_vW]

Ein stelle immer den Geräte-Port und Geräte Betriebszustand auf "aus" danach wieder auf "ein" und dann läuft wieder alles.

[alf29]

Moin,

Gibt's dafür irgendwelche Bugreports Richtung LANCOM-Support? Wenn ja, hast Du im Fehlerfall Traces vom COM-Port-Server eingereicht?

Aus- und wieder Einschalten führt erstmal dazu, daß eine existierende TCP-Verbindung zerstört wird und im Server-Modus neu aufgebaut werden muß. Wenn's auf der seriellen Seite klemmt und man nur die hätte irgendwie neu initialisieren müssen, war das Zerstören der TCP-Verbindung überflüssig. Mag sein, daß Aus- und Einschalten Dir hilft, aber ich würde gerne wissen, wo die eigentliche Ursache solcher Probleme liegt und die dann versuchen zu lösen, anstatt mit dem Holzhammer draufzuhauen.

Gruß Alfred

[Koppelfeld]

...Postings in diesem Ton führen aber dazu, daß am nächsten Tag ein panischer PM die Weisung ausgibt, der WAN-Zugriff sollte doch bitte komplett und ohne Einstellmöglichkeit abgeklemmt werden. Und wie 'glücklich' dann potentiell andere Kunden über so eine Kurzschlußreaktion sind, kann man hier im Forum am SIP nachlesen...

Alfred, damit sprichst Du mir aus der Seele...

Hmmm.
Das mit der Großschreibung war offensichtlich keine böse Absicht, es muß heutzutage nicht jeder die Regeln des USENET mehr kennen. Dafür kenne ich keine "Smileys" oder weiß nicht, was "liken" ist.
Das Posting selbst ist sachlich gehalten,
der Inhalt ist absolut wichtig !
Denn, schuldig im Sinne der Anklage, den Comport-Server benutze ich auch.
Und weil die Drecks-Mickysoft/Intel - "Server" keine serielle Schnittstelle mehr haben dürfen, qua Generalverfügung von Steve Ballmer, steckt da bei uns typischerweise die Konsole einer pSeries drauf. Denn die haben, ein kaum zu unterschätzender Vorteil, keine "Graphikkarte" und brauchen kein "KVM" oder gar so eine "ILO"- (HP) oder "RSA"- (IBM) Karte. Einfach die, im Gegensatz zu "U"SB, wirklich universelle Schnittstelle einstöpseln und streßfrei loslegen, ohne VGA/DVI/HDMI-Adaptergedöns und ohne "Maus", von überall aus.
Da war der Comport-Server eine feine Sache. Und ich bin einfach implizit davon ausgegangen, daß jener nicht über die WAN-Adresse erreichbar ist.
Wenn man bei einer Firma Microsoft stillegt, geht ja meistens das Tagesgeschäft weiter, nur effizienter. Und die User sind das gewohnt. Aber wenn man solche Sachen wie AIX oder OS/400 abschaltet, dann steht der Laden. Und verantwortlich wäre dann ich, wenn ein Angriff über den Comport-Server erfolgt wäre.

Insofern möchte ich mich für den Hinweis bedanken.

[alf29]

Da war der Comport-Server eine feine Sache. Und ich bin einfach implizit davon ausgegangen, daß jener nicht über die WAN-Adresse erreichbar ist.

Das ist im LCOS genauso wie mit einem Listener auf einem Unix-System: solange das nicht explizit über irgendwelche Firewall-Einträge oder Binding-Optionen abgeschaltet ist, nimmt er erstmal Verbindungen von beliebigen Adressen an.

Gruß Alfred

[Christoph_vW]

Moin,
Gibt's dafür irgendwelche Bugreports Richtung LANCOM-Support? Wenn ja, hast Du im Fehlerfall Traces vom COM-Port-Server eingereicht?

nein und nein

Für Traces bleibt mir in der Regel keine Zeit, Nutzer jammert immer gleich los.

[Jirka]

Hallo zusammen,

Ich denke, die Mehrzahl der Nutzer dec COM-Port-Servers (das sind a priori nicht so viele) nutzt ihn nicht auf dem Internet-Gateway selber, sondern z.B. auf irgendeinem AP intern.

definitiv! Oder über einen älteren LANCOM-Router, der sich in der Nähe der benötigten seriellen Schnittstelle befindet. Denn oftmals befindet sich der eigentliche Router viel weiter weg. Insofern kommt vermutlich noch nicht mal auf 1.000 LANCOM-Router (mit WAN-IP) einer mit aktiviertem COM-Port-Server.

Postings in diesem Ton

Soweit ich von Rougu gehört habe, ist er etwas genervt aus dem SIP-Bereich, wo die Reaktionszeiten etwas anders liegen, als wenn hier jetzt einer ein Problem mit dem COM-Port-Server hat, wo ein Entwickler noch am selben Tag reagiert und dazu noch am Sonntag.

Was am Posting nicht stimmt, ist insbesondere das Wort "Grusel". Denn das ist wirklich übertrieben. Das mit der Großschreibung sehe ich wie Koppelfeld, ich habe selber schon x-mal von mir geschriebene Sachen, auch in E-Mails korrigiert, weil es eine weitverbreitete Meinung gibt, dass Großschreibung mit schreien gleichgesetzt wird - ich persönlich sehe das eher als Mittel zur Hervorhebung und Betonung.

Für Traces bleibt mir in der Regel keine Zeit, Nutzer jammert immer gleich los.

Und wenn man entsprechende Traces schon vorsorglich startet?

Viele Grüße,
Jirka

[alf29]

Moin,

Was am Posting nicht stimmt, ist insbesondere das Wort "Grusel". Denn das ist wirklich übertrieben. Das mit der Großschreibung sehe ich wie Koppelfeld, ich habe selber schon x-mal von mir geschriebene Sachen, auch in E-Mails korrigiert, weil es eine weitverbreitete Meinung gibt, dass Großschreibung mit schreien gleichgesetzt wird - ich persönlich sehe das eher als Mittel zur Hervorhebung und Betonung.

Klassisch im Usenet bedeutet alles in Großschrift 'schreien'. Wenn man dort etwas nur hervorheben wollte, hat man den Textteil in Sternchen gesetzt, oder in Slashes, um Kursivschrift anzudeuten. Hier in einem Web-Forum braucht man weder das eine noch das andere, da kann man den Textteil einfach fett setzen.

Gruß Alfred

[cpuprofi]

Hallo Alfred,

Moin,

Was am Posting nicht stimmt, ist insbesondere das Wort "Grusel". Denn das ist wirklich übertrieben. Das mit der Großschreibung sehe ich wie Koppelfeld, ich habe selber schon x-mal von mir geschriebene Sachen, auch in E-Mails korrigiert, weil es eine weitverbreitete Meinung gibt, dass Großschreibung mit schreien gleichgesetzt wird - ich persönlich sehe das eher als Mittel zur Hervorhebung und Betonung.

Klassisch im Usenet bedeutet alles in Großschrift 'schreien'. Wenn man dort etwas nur hervorheben wollte, hat man den Textteil in Sternchen gesetzt, oder in Slashes, um Kursivschrift anzudeuten. Hier in einem Web-Forum braucht man weder das eine noch das andere, da kann man den Textteil einfach fett setzen.

Gruß Alfred

ich denke Jirka's Generation kennt die Gepflogenheiten des Usenet nicht (meistens noch nicht einmal den Ursprung des Usenet selber oder verwechsel es mit einer Tausch-/Download-Börse... ), da diese Generation ja eine ganze Ecke jünger ist...

Grüße
Cpuprofi

[alf29]

So wird's in Zukunft aussehen:

Code: Alles auswählen

root@lc1781efpb-aa:/Setup/COM-Ports/COM-Port-Server/Network-Settings/Outband  0
> set ?

Possible input for columns in table 'Network-Settings':
[  1] Device-Type            : value fixed
[  2] Port-Number            : value fixed
[  4] TCP-Mode               : Server (0), Client (1)
[  5] Listen-Port            : 5 chars from 1234567890
[ 17] WAN-Access             : No (0), Yes (1), VPN-Only (2)
[  6] Connect-Hostname       : 48 chars from #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[  7] Connect-Port           : 5 chars from 1234567890
[  8] Loopback-Addr.         : 16 chars from ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()+-,/:;<=>?[\]^_.0123456789
[  9] RFC2217-Extensions     : No (0), Yes (1)
[ 16] Binary-Mode            : Auto (0), Yes (1), No (2)
[ 10] Newline-Conversion     : CRLF (0), CR (1), LF (2)
[ 14] TCP-Keepalive          : inactive (0), active (1), proactive (2)
[ 15] TCP-Keepalive-Interval : 10 chars from 1234567890
[ 12] TCP-Retransmit-Timeout : 2 chars from 1234567890
[ 13] TCP-Retry-Count        : 1 chars from 1234567890

Allerdings nur ab LCOS 10.12 .

Gruß Alfred

[MoinMoin]

Moin Alfred!

Ich nehme an der Default ist Yes? Ansonsten gibt es sicherlich erhöhtes Supportaufkommen, weil plötzlich der Zugang über WAN nicht mehr geht.

Ciao, Georg