LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

[Jirka]

Und wie mache ich das ohne das Verwenden eines M$-abhängigen Produktes?

In LANconfig konfigurieren Sie die Einstellungen zum SYSLOG-Server unter Meldungen/Monitoring > Protokolle > SYSLOG über SYSLOG-Server.
Klicken Sie auf SYSLOG-Server, um die vorhandenen SYSLOG-Einträge anzuzeigen.

In WEBconfig, wie Backslash doch schon geschrieben hat. Und wo da, hast Du hier doch genau schon hingeschrieben. Du willst doch dafür jetzt keine Klick-Anleitung oder einen Screenshot, oder?
Also ich versuche es mal mit einer Klickanleitung: Du machst WEBconfig auf. Dazu öffnest Du einen halbwegs aktuellen Browser Deiner Wahl und gehst damit auf die IP-Adresse Deines LANCOM-Routers und loggst Dich ein. Soweit sicherlich klar. Jetzt klickst Du links im Menü auf Konfiguration -> Meldungen/Monitoring -> Protokolle und dann rechts auf Syslog-Server. Dort suchst Du jetzt einen Eintrag (eine Zeile), wo in der Spalte Router der Wert An steht und klickst diese Zeile vorne an (in Höhe der ersten Spalte in der Tabelle: Adresse des Servers). Jetzt sollte der Rest selbsterklärend sein.
Ach ja, falls nach dem Thread-Verlauf doch noch nicht selbsterklärend, hier noch eine entscheidende Stelle von oben zitiert:

Einfach für die Quelle "Router" den Level "Info" hinzunehmen...

[plumpsack]

In WEBconfig, wie Backslash doch schon geschrieben hat.

Backslash hatte da gar nichts beschieben.

Ich hatte ihn auf eine Anleitung verwiesen.

Du machst WEBconfig auf. ...
Jetzt klickst Du links im Menü auf Konfiguration -> Meldungen/Monitoring -> Protokolle und dann rechts auf Syslog-Server. Dort suchst Du jetzt einen Eintrag (eine Zeile), wo in der Spalte Router der Wert An steht und klickst diese Zeile vorne an (in Höhe der ersten Spalte in der Tabelle: Adresse des Servers). Jetzt sollte der Rest selbsterklärend sein.

Web-Interface:

Code: Alles auswählen

--> Configuration
--> Logging/Monitoring
--> Logging/Monitoring: Protocols
	--> SYSLOG servers
		/config2/5/3?table_val003_display
		/config2/5/3/?table_val003_edit_8
	

Da soll ich jetzt zu "Alert" -> (zusätzlich) "Information" aktivieren?

Geht's noch?

Information ist sowas wie MOTD .. das benötige ich nicht!

Ich möchte, das Alarm weiterhin, wie gehabt, im Syslog steht:

Code: Alles auswählen

LOCAL3 	Alarm	Dst:

Und warum steht im "RN_LCOS-1072-RU1_DE.pdf"

„Connection Refused“-Meldungen werden nun im Syslog mit Level ‚Info‘ statt
„Alarm“ angezeigt. Dies führt dazu, dass diese Meldungen nicht mehr im
Syslog der WEBconfig im Default angezeigt werden. Das Verhalten kann durch
eine Konfigurationsänderung angepasst werden.

Da wird gar nix angezeigt!

Ich glaube ihr hattet echt nicht verstanden was ich hier geschrieben hatte ...

[Jirka]

Backslash hatte da gar nichts beschrieben.

Das ist nicht wahr! Im Gegenteil, er hat mehrfach und geduldig was geschrieben:

steht doch schon in den Release-Notes drin... Einfach für die Quelle "Router" den Level "Info" hinzunehmen...

ein paar Klicks weiter landest du dann hier https://www.lancom-systems.de/docs/LCOS ... erver.html

Eigentlich sagt die Tabelle nur, welche Syslog-Events an welchen Server geschickt werden. Und alles, was an die 127.0.0.1 geschickt wird, landet in der internen Syslog-Tabelle.
Und in der lezten Zeile ist der Eintrag, der die Events der Kategorie "Router" steuert - dort "Information" anhaken und die "connection refused" Meldungen tauchen wieder auf...

WEBconfig...

Wem das nicht reicht, der kann allenfalls mal freundlich nachfragen! Aber mehr nicht.

Da soll ich jetzt zu "Alert" -> (zusätzlich) "Information" aktivieren?

Wenn Du diese Meldungen nach wie vor sehen möchtest, ja.

Geht's noch?
Information ist sowas wie MOTD .. das benötige ich nicht!

Sachen, die Du nicht benötigst könntest Du wiederum ausfiltern.

Ich möchte, das Alarm weiterhin, wie gehabt, im Syslog steht:

Das geht nicht. Das war ein Fehler es jemals in Alarm einzusortieren, weil es niemals ein Alarm war. Diese Zuordung kann nicht geändert werden, es kann nur die Facility-Zuordnung geändert werden.

Ich glaube ihr hattet echt nicht verstanden was ich hier geschrieben hatte ...

Das ist ja öfter das Problem. Deswegen bitte bemühen, genau zu beschreiben, was Dein Problem ist.

[Dr.Einstein]

Wie soll ich das sagen, wenn ich nicht einmal weiß welche Meldungen in der 10.72.0091-RU1 noch alles andere gegenüber der 10.72.0015-Rel

via SSH / WebConfig unter

Code: Alles auswählen

ls /status/voiice-call-manager/lines
-> registered-since

nachprüfbar. Mit 10.72RU1 hatte ich schon Meldungen bzgl. changed order. Diese waren aber korrekt, da sich der Telekom Server verändert hatte.

[plumpsack]

Ich möchte, das Alarm weiterhin, wie gehabt, im Syslog steht

Das geht nicht. Das war ein Fehler es jemals in Alarm einzusortieren, weil es niemals ein Alarm war. Diese Zuordung kann nicht geändert werden, es kann nur die Facility-Zuordnung geändert werden.

Das mit dem Alarm, wenigstens via UDP*, war der beste Indikator dafür, um zu sehen, von woher der Wind weht!
* leider keine TCP Meldungen

Auch wenn sich von euch, allem Anschein nach, niemand die Mühe gemacht hatte die IP-Adressen und die Besitzer der IP-Adressen auswendig zu machen.

RU, CN, BZ, BR, IR, CY, PK, BG, VE, PA, ID, UA, AE und Co. kamen da nicht sellten vor!

Fällt euch da etwas auf?

Das jetzt im Nachhinein als "Fehler" zu bezeichnen halte ich als "grob fahrlässig"!

Siehe hierzu:
https://www.heise.de/news/EU-Cyber-Sich ... 22269.html

Für die Erkennung seien etwa ein ordentliches Logging, das Überwachen von Meldungen durch vorhandene Sicherheitskomponenten, Überwachung von Aktivitäten von Netzwerkgeräten sowie der Einsatz von Erkennungssoftware wie Intrusion-Detection-Systemen zu empfehlen.

Was kommt als nächstes, das Black Hole Device wird rausgeschmissen?

https://en.wikipedia.org/wiki/Black_hole_(networking)

[plumpsack]

Mit 10.72RU1 hatte ich schon Meldungen bzgl. changed order. Diese waren aber korrekt, da sich der Telekom Server verändert hatte.

Ich setze die 10.72RU1 nicht ein. Nicht einmal bei dem letztens zusätzlich gekauften 883-Voip.

Zumindest nicht mit der 10.72RU1 - bis der Mist geklärt wurde.

Für mich ist die 10.72RU1 ein Vertrauensbruch!

[plumpsack]

Aktueller Nachtrag:

Faeser warnt vor Sabotage durch ...

hmmm ...

"Houston, wir haben zu viel "Hintergrundrauschen" ..."

hahaha, sorry, aber den konnte ich mir gerade echt nicht verkneifen.

[plumpsack]

LCOS-Änderungen 10.50.1107 RU10 und Co. - plus.

Wenn ein Netzwerk-Teilnehmer im lokalen Netzwerk des Routers eine DNS-
Anfrage zu schnell wiederholt, wird eine zweite DNS-Anfrage mit dem
gleichen Quell-Port an den Backup-DNS-Server geschickt. Nach Erhalt der
Antwort eines der beiden DNS-Server wird der Port geschlossen. Erhält der
Router anschließend auch noch die Antwort des zweiten DNS-Servers, wird
diese abgelehnt.
Dadurch wurde die Meldung „connection refused“ im Syslog aufgezeichnet
(Priorität ‚Alarm‘). Durch dieses Verhalten konnte es vorkommen, dass im
Syslog viele ‚False Positive‘-Meldungen aufgezeichnet wurden. Die Priorität
der Meldung „connection refused“ wurde jetzt auf ‚Info‘ geändert, sodass
diese in der Standard-Konfiguration nicht im Syslog aufgezeichnet wird.

Ich glaub das nicht ... !!!

Was für ein "Schmarren" !!!

„connection refused“ kommen fast aussließlich von externen, UNERWÜNSCHTEN, Anfragen!

St. Petersburg / Moscow und Co. oder CHINANET.

Ich hoffe die Telekom bleibt bei der 10.50.1077 bis das geklärt wurde!

[tstimper]

LCOS-Änderungen 10.50.1107 RU10 und Co. - plus.

Wenn ein Netzwerk-Teilnehmer im lokalen Netzwerk des Routers eine DNS-
Anfrage zu schnell wiederholt, wird eine zweite DNS-Anfrage mit dem
gleichen Quell-Port an den Backup-DNS-Server geschickt. Nach Erhalt der
Antwort eines der beiden DNS-Server wird der Port geschlossen. Erhält der
Router anschließend auch noch die Antwort des zweiten DNS-Servers, wird
diese abgelehnt.
Dadurch wurde die Meldung „connection refused“ im Syslog aufgezeichnet
(Priorität ‚Alarm‘). Durch dieses Verhalten konnte es vorkommen, dass im
Syslog viele ‚False Positive‘-Meldungen aufgezeichnet wurden. Die Priorität
der Meldung „connection refused“ wurde jetzt auf ‚Info‘ geändert, sodass
diese in der Standard-Konfiguration nicht im Syslog aufgezeichnet wird.

Ich glaub das nicht ... !!!

Was für ein "Schmarren" !!!

„connection refused“ kommen fast aussließlich von externen, UNERWÜNSCHTEN, Anfragen!

St. Petersburg / Moscow und Co. oder CHINANET.

Ich hoffe die Telekom bleibt bei der 10.50.1077 bis das geklärt wurde!

Eine vieleicht wahre Geschichte

Supporter 1, 2, Entwickler 1,2 betreten die Bühne.
PM steht am Rande und beobachtet die Szene

Supporter 1: ich habe hier ettliche Cases, wo die Kunden DNS connection refused im Log sehen

Supporter 2: ja wir hatten das letzes Jahr auch auf einem WLC in einem case mit ts, eine Lösung gab es nicht, Entwickler 1, kannst Du dir das erklären?

Entwickler 1: Ja, wenn die Anfrage zweimal hinternander kommt, nehmen wir einfach denselben Quellport
Entwickler 2 : Häh?
Entwickler 1: Sonnst läuft die Tabelle wieder über ...
Entwickler 2 : Mh ... und was machen wir jetzt?
Entwickler 1: Frag mal den PM
PM: (ruft vom Bühnenrand) macht doch einfach die zweite Meldung aus
Entwickler 2: das geht nicht, kostet extra Zeit zur Laufzeit, weil wir immer schauen müssen, ob es schon ein erstes paket gab
PM: (ruft vom Bühnenrand)Dann mach einfach alle Notification aus.
Entwickler 1: Das geht, aber ...
Supporter 1 und 2 freudig im Chor: Das spart uns Arbeit
PM: (ruft vom Bühnenrand) ok macht das so
Entwickler 2: aber ...
PM: (ruft vom Bühnenrand)schreibts in die Release notes, dann ists ok
Supporter 1: Plumpsack wird sich im Forum wieder aufregen...
Supporter 2: ts wird das auch auffallen
PM: egal, irgendwas müssen wir machen, notfalls schreib ich da das wie es nicbt allen Recht machen können und eine Balance
zwischen Aufwand und Nutzen finden müssen

Ende.

Viele Grüße

ts

[plumpsack]

Eine vieleicht wahre Geschichte
...
Supporter 1: ich habe hier ettliche Cases, wo die Kunden DNS connection refused im Log sehen

Ende.

Thema verfehlt!

Jeden Tag grüßt der Russe oder der Chinese, manchmal auch der Brasilianer oder auch die anderen bei denen ich echt kein Urlaub machen wollte, vor 10 Jahren evtl., mit "connection refused" am Lancom!

Das hat mit DNS aber auch gar nichts zu tun!

[plumpsack]

Da könnten die Youngster Admins wieder schnell auf die Idee kommen, das es sich hier nur um "Hintergrundrauschen" handelt.

genau das ist das zu 99,9999999998% auch...

Könntest du mal ein paar Beispiele posten die das mit deiner 99,9999999998%igen Aussage belegen können?

Hier wurde gerade wieder ein Unternehmen "gehackt" - und ich "denke" es ging über eine lange Zeit.

Angefangen vom Spear Phishing über WLAN-Hacking und Co. - Ergebnis: "mission accomplished"!

Mal gucken was da an die Öffentlichkeit noch kommt ...

Aber ich freu mich über dein Posting ...

[plumpsack]

Könntest du mal ein paar Beispiele posten die das mit deiner 99,9999999998%igen Aussage belegen können?

Kommt nix .. weil ... deine Aussage nicht stimmt!

Wieder so ein neues "Hintergrundrauschen" - 162.216.148.0/22 - braucht kein Darmausgang ...

[backslash]

nein, da kommt nichts, weil ich es nichts bringt, dir zu antworten!

aber gerne nochmal: Das LANCOM hat keinen Listener für das Paket und daher gab es die "connection refuised" Meldung. Es ist aber kein Problem, da das Paket am LANCOM endet. Ein Problem sind Fälle, die ohne Meldung "durchkommen" und wirklich Schaden anrichten - gegen die helfen aber "Panik-Meldungen", die sagen, daß ein Paket verworfen wurde (auch wenn das die diversen Redakteure von Consumer-Computerzeitungen so geil finden). Sie sorgen nur dafür, daß Leute bei einem Fehler an der falschen Stelle suchen.

Um dein Netz zu sichern reicht eine Deny-All-Regel in der Firewall und sichere Paßwörter für die Router-Konfig (ggf. noch Filter für den Zugriff auf die Config: Admin -> Zugriffseinstellungen -> Zugriffs-Rechte/Zugriffs-Stationen). Alles andere ist "Bling-Bling" ohne echten Mehrwert.