R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

plumpsack · Beitrag von **plumpsack** » 03 Jul 2019, 20:17

Hallo,

ich habe hier u.A. einen R883VAW mit der Firmware 10.20.0302 / 17.04.2019.

Nach jeder Zwangstrennung, Verbindungsabbruch, bzw. Neueinwahl, bekomme ich ein "intruder detection" im Firewall-Log.

Code: Alles auswählen

Idx.	System-time	Src-Address	Dst-Address	Prot.	Src-Port	Dst-Port	Filter-Rule	Limit	Threshold	Action
0001	07/03/2019 10:45:25	185.176.27.2	xxx.xxx.xxx.xxx	6	44012	33589	intruder detection	00000001	0	60024800
0002	07/02/2019 10:46:22	81.22.45.251	xxx.xxx.xxx.xxx	6	56099	5900	intruder detection	00000001	0	60024800
0003	07/01/2019 10:44:55	185.176.27.174	xxx.xxx.xxx.xxx	6	45607	3404	intruder detection	00000001	0	60024800
0004	06/30/2019 10:44:52	92.118.37.84	xxx.xxx.xxx.xxx	6	41610	57742	intruder detection	00000001	0	60024800
0011	06/29/2019 10:44:59	81.22.45.148	xxx.xxx.xxx.xxx	6	48515	33883	intruder detection	00000001	0	60024800
0012	06/29/2019 00:00:43	81.22.45.219	xxx.xxx.xxx.xxx	6	44113	44895	intruder detection	00000001	0	60024800
0013	06/27/2019 23:59:26	185.176.27.174	xxx.xxx.xxx.xxx	6	51374	20043	intruder detection	00000001	0	60024800
0014	06/27/2019 08:14:39	92.118.37.84	xxx.xxx.xxx.xxx	6	41610	9692	intruder detection	00000001	0	60024800
0015	06/26/2019 08:14:12	185.176.27.90	xxx.xxx.xxx.xxx	6	58851	3747	intruder detection	00000001	0	60024800
0016	06/26/2019 06:05:44	112.164.187.153	xxx.xxx.xxx.xxx	6	7377	8080	intruder detection	00000001	0	60024800
0017	06/26/2019 05:48:30	46.3.96.71	xxx.xxx.xxx.xxx	6	44142	47018	intruder detection	00000001	0	60024800
0018	06/26/2019 02:06:33	92.118.37.84	xxx.xxx.xxx.xxx	6	41610	58070	intruder detection	00000001	0	60024800
0019	06/25/2019 02:05:29	185.176.27.30	xxx.xxx.xxx.xxx	6	59761	14583	intruder detection	00000001	0	60024800
001a	06/24/2019 02:04:50	125.212.217.214	xxx.xxx.xxx.xxx	6	26200	2052	intruder detection	00000001	0	60024800
001b	06/23/2019 02:05:11	46.3.96.68	xxx.xxx.xxx.xxx	6	56038	8807	intruder detection	00000001	0	60024800
001c	06/22/2019 02:04:50	92.118.37.84	xxx.xxx.xxx.xxx	6	41610	14604	intruder detection	00000001	0	60024800
001d	06/21/2019 02:04:14	92.118.37.84	xxx.xxx.xxx.xxx	6	41610	49073	intruder detection	00000001	0	60024800
001e	06/20/2019 02:04:23	77.247.109.30	xxx.xxx.xxx.xxx	6	41207	3793	intruder detection	00000001	0	60024800
0020	06/19/2019 14:51:04	189.34.106.250	xxx.xxx.xxx.xxx	6	39556	8080	intruder detection	00000001	0	60024800
0022	06/18/2019 20:45:42	185.176.27.254	xxx.xxx.xxx.xxx	6	53764	3371	intruder detection	00000001	0	60024800
0023	06/17/2019 20:46:14	185.176.27.42	xxx.xxx.xxx.xxx	6	51199	420	intruder detection	00000001	0	60024800
0024	06/16/2019 20:45:52	92.118.37.70	xxx.xxx.xxx.xxx	6	58594	3321	intruder detection	00000001	0	60024800
0027	06/15/2019 20:45:40	120.52.152.18	xxx.xxx.xxx.xxx	6	49019	631	intruder detection	00000001	0	60024800
0028	06/14/2019 20:45:49	77.247.110.153	xxx.xxx.xxx.xxx	17	5070	5060	intruder detection	00000001	0	60024800
0029	06/13/2019 20:48:30	112.164.187.151	xxx.xxx.xxx.xxx	6	29294	80	intruder detection	00000001	0	60024800
002a	06/12/2019 20:47:06	178.128.0.150	xxx.xxx.xxx.xxx	17	36479	53413	intruder detection	00000001	0	60024800
002b	06/11/2019 20:45:49	81.22.45.11	xxx.xxx.xxx.xxx	6	55968	33381	intruder detection	00000001	0	60024800
002c	06/10/2019 21:34:57	77.247.110.106	xxx.xxx.xxx.xxx	6	51937	80	intruder detection	00000001	0	60024800
002d	06/09/2019 21:36:17	81.22.45.219	xxx.xxx.xxx.xxx	6	52917	53521	intruder detection	00000001	0	60024800
002f	06/08/2019 21:35:10	81.22.45.38	xxx.xxx.xxx.xxx	6	41327	4789	intruder detection	00000001	0	60024800
0030	06/07/2019 21:34:50	77.247.110.86	xxx.xxx.xxx.xxx	6	43415	2989	intruder detection	00000001	0	60024800
0031	06/06/2019 21:34:53	81.22.45.253	xxx.xxx.xxx.xxx	6	54712	9934	intruder detection	00000001	0	60024800
0032	06/05/2019 21:35:15	107.170.202.172	xxx.xxx.xxx.xxx	6	44372	27017	intruder detection	00000001	0	60024800
0033	06/04/2019 21:35:38	112.164.137.44	xxx.xxx.xxx.xxx	6	25143	23	intruder detection	00000001	0	60024800
0034	06/03/2019 21:34:50	122.224.19.6	xxx.xxx.xxx.xxx	6	48499	445	intruder detection	00000001	0	60024800
0035	06/03/2019 05:04:01	185.60.216.54	xxx.xxx.xxx.xxx	6	443	35488	intruder detection	00000001	0	60024800
0037	06/02/2019 05:07:45	81.22.45.193	xxx.xxx.xxx.xxx	6	41835	7318	intruder detection	00000001	0	60024800
0038	06/01/2019 05:06:12	146.185.25.187	xxx.xxx.xxx.xxx	6	8080	8080	intruder detection	00000001	0	60024800
003a	05/31/2019 05:06:52	77.247.108.79	xxx.xxx.xxx.xxx	17	5229	5060	intruder detection	00000001	0	60024800
003b	05/30/2019 05:03:58	125.64.94.220	xxx.xxx.xxx.xxx	6	60755	7778	intruder detection	00000001	0	60024800
003c	05/29/2019 05:03:29	3.15.75.161	xxx.xxx.xxx.xxx	1	0	0	intruder detection	00000001	0	60024800
003d	05/29/2019 02:00:27	185.60.216.54	xxx.xxx.xxx.xxx	6	443	59680	intruder detection	00000001	0	60024800
003e	05/28/2019 02:01:50	196.52.43.54	xxx.xxx.xxx.xxx	6	54211	9200	intruder detection	00000001	0	60024800
0047	05/27/2019 02:00:21	71.6.232.6	xxx.xxx.xxx.xxx	17	52412	161	intruder detection	00000001	0	60024800
0048	05/26/2019 02:00:21	71.6.158.166	xxx.xxx.xxx.xxx	6	30909	21	intruder detection	00000001	0	60024800
0049	05/25/2019 02:00:24	81.22.45.254	xxx.xxx.xxx.xxx	6	59028	19899	intruder detection	00000001	0	60024800
004a	05/24/2019 02:04:12	164.52.24.165	xxx.xxx.xxx.xxx	6	34288	21	intruder detection	00000001	0	60024800
004b	05/23/2019 02:00:16	128.199.240.173	xxx.xxx.xxx.xxx	6	61250	9090	intruder detection	00000001	0	60024800
004c	05/22/2019 02:00:23	81.22.45.191	xxx.xxx.xxx.xxx	6	54544	3012	intruder detection	00000001	0	60024800
004d	05/21/2019 02:01:41	172.104.9.33	xxx.xxx.xxx.xxx	17	55956	69	intruder detection	00000001	0	60024800
004e	05/20/2019 23:25:59	125.64.94.210	xxx.xxx.xxx.xxx	6	39786	3389	intruder detection	00000001	0	60024800

Die Src-Addressen bzw. Netzwerke sind in der Routing-Tabelle des R883VAW als blockiert, also gegen 0.0.0.0 gelenkt/hinterlegt.

Laut ftp://ftp.lancom.de/Documentation/Relea ... RU6_DE.pdf

"LCOS-Änderungen 10.20.0369 RU4 > 10.20.0446 RU5"

"Bezog ein Router oder Access Point seine IP-Adresse per DHCP, kam es beim Empfang von IP-Paketen
außerhalb des lokalen Netzwerkes auf dem DHCP-Interface zu einem Fehler beim Auflösen der Routen.
In der Folge lehnte die Firewall des Gerätes die IP-Pakete mit der Meldung „Intruder detection“ ab."

Ist das immer noch dieser Fehler?

Wenn ja, warum wurde dieser Fehler noch nicht beseitigt?

backslash · Beitrag von **backslash** » 04 Jul 2019, 10:33

Hi plumpsack

Die Src-Addressen bzw. Netzwerke sind in der Routing-Tabelle des R883VAW als blockiert, also gegen 0.0.0.0 gelenkt/hinterlegt.

und dann wunderst du dich, daß das LANCOM den Empfang einen Pakets von diesen Adresse von der Internet-Gegenstelle als Einbruchsversuch wertet?...

Ist das immer noch dieser Fehler?

nein, das ist kein Fehler, sondern "works as configured"... mich wundert eigentlich nur, daß das nur nach dem Neuverbinden passieren soll. Eigentlich müßte das immer passieren, sobald ein Paket von diesen Adessen kommt, denn du hast ja durch die Sperr-Route (0.0.0.0) explizit gesagt, daß Paket von diesen Adressen von NIRGENDWO empfangen werden dürfen.

Gruß
Backslash

plumpsack · Beitrag von **plumpsack** » 05 Jul 2019, 16:55

Hallo Backslash,

danke für deine Rückantwort.

Heute noch einmal ausprobiert:

883VOIP 10.30.0163 / 03.07.2019
Konfiguration wie bei
R883VAW 10.20.0302 / 17.04.2019

Gleich nach einer Einwahl:

Idx. System-time Src-Address Dst-Address Prot. Src-Port Dst-Port Filter-Rule Limit Threshold Action
0001 07/05/2019 15:08:29 46.3.96.70 xxx.xxx.xxx.xxx 6 46981 11304 intruder detection 00000001 0 60024800

Konfiguration:
Keine DMZ
Kein IPV6
Deny all Strategie
Eigene Routing-Tabelle
Eigene DNS-Filter

A) Löschen der eigenen Routing-Tabelle

-->

Routing_2019_07_05-blanc_eng.lcs

Nach Einwahl:

Friede, Feuer, Eierkuchen.

Dachte ich.

Nachdem ich aber, im laufenden Betrieb, meine Routing-Tablelle (Routing_2019_07_05-2_eng.lcs) eingespielt hatte, ging der Spaß wieder los.

Wie du im Eingangsposting siehst, sind die IP-Adressen alle belastet.

Eine einfache Suche der IP-Adressen, markieren und Google suchen lassen, sollte da eigentlich abuseipdb auftauchen lassen.

Ich poste hier mal meine zwei Routing-Tabellen zum Testen.

Wenn das mit dem "intruder detection" bei der Einwahl kein Fehler sein sollte, ist mir das dann auch egal, weil ich somit sicher stellen kann, das mein Netzwerk sich nicht mit diesen dubiosen IP-Adressen/Netzwerken verbinden kann.

Routing_2019_07_05-blanc_eng.lcs.gz
blockiert nur private und multicast-Netzwerke

Routing_2019_07_05-2_eng.lcs.gz
blockiert alle unerwünschten Netzwerke

PS: In der Routing_2019_07_05-2_eng.lcs sind nicht nur böse Netzwerke, da sind auch "unerwünschte" Netzwerke drin.

plumpsack · Beitrag von **plumpsack** » 07 Jul 2019, 18:51

Hallo,

in der Anlage noch einmal die Routing-Tabellen für eine 1UND1-Verbindung mit deutscher Konfiguration eines Lancom-Routers,
hier ein 884VOIP mit 10.30.0163 / 03.07.2019.

Code: Alles auswählen

add  255.255.255.255  0.0.0.0          0        "1UND1"           0         Ein         ja       "Diese Route wurde durch den Internet-Assistenten erzeugt"

Ein Bekannter hatte diese Routing-Tabellen ausprobiert.

1UND1_blanc_2019_07_07_dt.lcs, blockiert Android-Chrome-Google-DNS 8.8.8.8 und 8.8.4.4 sowie private und Multicast-Netzwerke.

Er hatte in seinen Einstellungen in Lanconfig unter Firewall DoS sowie IDS Verbindung trennen nach Attacke eingestellt.

Soweit so gut, keine Verbindungsabbrüche.

Nach dem Einspielen von 1UND1_full_2019_07_07_dt.lcs kam es zu extremen Verbindungsabbrüchen.

Erst nach dem Entfernen/Deaktivieren der Option Verbindung trennen unter DoS und IDS blieb die Verbindung stabil.

Allerdings wurden die Attacken nicht mehr, weder im Sys- noch im Firewall-Log, gemeldet.

Auch hier kam es jetzt, mit der 1UND1_full_2019_07_07_dt.lcs, nach jeder neuen Einwahl zu einem "intrusion detection".

Code: Alles auswählen

2019-07-07 16:37:24;19;1;Dst: xxx.xxx.xxx.xxx:8068 {LC884.intern}, Src: 185.176.27.62:44170 (TCP): intrusion detection;
2019-07-07 16:07:25;19;1;Dst: xxx.xxx.xxx.xxx:5058 {LC884.intern}, Src: 92.118.37.43:49067 (TCP): intrusion detection;
2019-07-07 16:06:10;19;1;Dst: xxx.xxx.xxx.xxx:405 {LC884.intern}, Src: 92.118.37.84:41610 (TCP): intrusion detection;
2019-07-07 16:05:08;19;1;Dst: xxx.xxx.xxx.xxx:59261 {LC884.intern}, Src: 92.118.37.84:41610 (TCP): intrusion detection;
2019-07-07 16:03:40;19;1;Dst: xxx.xxx.xxx.xxx:80 {LC884.intern}, Src: 74.82.47.50:46474 (TCP): intrusion detection;
2019-07-07 16:01:36;19;1;Dst: xxx.xxx.xxx.xxx:27768 {LC884.intern}, Src: 92.118.37.84:41610 (TCP): intrusion detection;
2019-07-07 16:00:26;19;1;Dst: xxx.xxx.xxx.xxx:17458 {LC884.intern}, Src: 92.118.37.84:41610 (TCP): intrusion detection;
2019-07-07 15:59:11;19;1;Dst: xxx.xxx.xxx.xxx:5060 {LC884.intern}, Src: 77.247.110.153:5096 (UDP): intrusion detection;
2019-07-07 15:58:06;19;1;Dst: xxx.xxx.xxx.xxx:10003 {LC884.intern}, Src: 81.22.45.219:44113 (TCP): intrusion detection;
2019-07-07 15:57:01;19;1;Dst: xxx.xxx.xxx.xxx:5555 {LC884.intern}, Src: 113.253.58.160:44160 (TCP): intrusion detection;
2019-07-07 15:55:53;19;1;Dst: xxx.xxx.xxx.xxx:5702 {LC884.intern}, Src: 92.118.37.43:49067 (TCP): intrusion detection;
2019-07-07 15:51:44;19;1;Dst: xxx.xxx.xxx.xxx:15998 {LC884.intern}, Src: 80.82.64.127:42234 (TCP): intrusion detection;

Warum ist das noch nicht vorher aufgefallen?

backslash · Beitrag von **backslash** » 08 Jul 2019, 11:33

Hi plumpsack

als erstes: TL/DR...

aber:

Erst nach dem Entfernen/Deaktivieren der Option Verbindung trennen unter DoS und IDS blieb die Verbindung stabil.

auch das ist: "works as konfigured"...

Der ganze Mist wie "Adressen sperren" und "Verbindung trennen" ist in der Firewall nur drin, weil diverse selbsternannte Experten verschiedenster Computerzeitschriften sowas toll finden. Wie du selbst gesehen hast, führt sowas am Ende erst recht zu einem erfolgreichen DoS-Angriff. Daher: So einen Mist niemals nutzen!

Gleiches gilt i.Ü. auch für Ping-Blockieren und Stealth-Mode... Denn keine Antwort bedeutet nicht, daß dort niemand ist - keine Antwort ist ein roter blinkender Pfeil auf das Ziel... Denn wäre dort wirklich niemand, dann würde schon der Routrer vorher ein "ICMP destination unreachble" zurückschicken. Aber auch der Mist wird von den oben erwähnten Leuten geliebt und als Sicherheitsfeature bezeichnet

Und noch etwas allgemeines zu "Angriffen" nach einer Neueinwahl: Da die Provider allesamt die IP-Adressen dynamisch vergeben, kannst du bei einer Neueinwahl auch eine bekommen, die kurz vorher noch mit den von dir in den Sperr-Routen aufgeführten Netzen kommuniziert haben. Dann können natürllich noch Pakete von dort kommen - das sind aber KEINE Angriffe.

Am besten löschst du alle deine Sperr-Routen (bis auf die für die privaten Netze, die im Default schon drin sind) und entfernst auch alle "Sperr-" oder "Trenn-" Aktionen bei IDS/DOS. Das öffnet i.Ü. keine Sicherheitslücken, da aufgrund des NAT auf einer IPv4-Vervbindung Verbindungen von "aussen" nach "innen" eh geblockt werden. Wenn du aber ganz sicher gehen willst, dann erstellst du in der Fierwall eine Deny-All Regel und Regeln die nur den gewünschten Traffic von "innen" nach "aussen" zulassen.

Gruß
Backslash

plumpsack · Beitrag von **plumpsack** » 09 Jul 2019, 18:25

backslash hat geschrieben: ↑08 Jul 2019, 11:33
Der ganze Mist wie "Adressen sperren" und "Verbindung trennen" ist in der Firewall nur drin, weil diverse selbsternannte Experten verschiedenster Computerzeitschriften sowas toll finden.

Lancom allem Anschein nach auch, sonst gäbe es diese Optionen nicht im LCOS.

backslash hat geschrieben: ↑08 Jul 2019, 11:33 Gleiches gilt i.Ü. auch für Ping-Blockieren und Stealth-Mode...
Aber auch der Mist wird von den oben erwähnten Leuten geliebt und als Sicherheitsfeature bezeichnet

Also Lancom.

backslash hat geschrieben: ↑08 Jul 2019, 11:33 Und noch etwas allgemeines zu "Angriffen" nach einer Neueinwahl: Da die Provider allesamt die IP-Adressen dynamisch vergeben, kannst du bei einer Neueinwahl auch eine bekommen, die kurz vorher noch mit den von dir in den Sperr-Routen aufgeführten Netzen kommuniziert haben. Dann können natürllich noch Pakete von dort kommen - das sind aber KEINE Angriffe.

Komisch nur, das mein Bekannter einen ganz anderen Provider (1UND1) nutzt und von den gleichen IP-Adressen, Netzwerken, penetriert wird.

backslash hat geschrieben: ↑08 Jul 2019, 11:33 Am besten löschst du alle deine Sperr-Routen (bis auf die für die privaten Netze, die im Default schon drin sind) und entfernst auch alle "Sperr-" oder "Trenn-" Aktionen bei IDS/DOS.

Das ist aber eine ganz ganz schlechte Idee.

Damit würde ich z.B. Android-Geräten und Google-Chrome-Browsern erlauben meine DNS-Filter zu umgehen,
da diese die DNS-Server 8.8.8.8 und 8.8.4.4 hard-coded haben.

Außerdem wurden im Syslog die Alarme durch meine Routing-Tabelle reduziert.

Warum sollte man die Alarme des Lancom-Routers ignorieren?
Da kann ich mir ja gleich eine Box aus Berlin anschließen.
Die macht gar keine Alarme.

backslash · Beitrag von **backslash** » 10 Jul 2019, 11:56

Hi plumpsack

Lancom allem Anschein nach auch, sonst gäbe es diese Optionen nicht im LCOS.

nein! wer lesen kann ist klar im Vorteil.. (aber nochmal für die ganz Dummen: es ist drin, weil diese "Experten" die Geräte sonst abwerten)

Also Lancom.

s.o.

Komisch nur, das mein Bekannter einen ganz anderen Provider (1UND1) nutzt und von den gleichen IP-Adressen, Netzwerken, penetriert wird.

was ist daran komisch? Die Quellen haben doch nichts mit dem Provider zu tun

Das ist aber eine ganz ganz schlechte Idee.

Damit würde ich z.B. Android-Geräten und Google-Chrome-Browsern erlauben meine DNS-Filter zu umgehen,
da diese die DNS-Server 8.8.8.8 und 8.8.4.4 hard-coded haben.

Wieso dass denn? Das müßtest du in deinem Regelsatz natürlich eplizit verbieten

Außerdem wurden im Syslog die Alarme durch meine Routing-Tabelle reduziert.

Warum sollte man die Alarme des Lancom-Routers ignorieren?
Da kann ich mir ja gleich eine Box aus Berlin anschließen.
Die macht gar keine Alarme.

Also, wenn du die Alarme sehen willst, dann darfst du auch nicht meckern, wenn sie kommen

Gruß0
Backslash

plumpsack · Beitrag von **plumpsack** » 11 Jul 2019, 20:30

Hallo Backslash,

backslash hat geschrieben: ↑10 Jul 2019, 11:56 was ist daran komisch? Die Quellen haben doch nichts mit dem Provider zu tun

Genau!
Es wäre nett gewesen, wenn du dir das mal genauer angeguckt hättest.
Ich mache diese Routing-Tabellen doch nicht aus Spaß und Jucks.

Guck dir doch mal z.B. "81.22.45.xxx" an.

backslash hat geschrieben: ↑10 Jul 2019, 11:56 Wieso dass denn? Das müßtest du in deinem Regelsatz natürlich eplizit verbieten

Hast du dir überhaupt einmal die Mühe gemacht, dir die Routing-Tabellen anzugucken?
Geschweige die einmal privat auszuprobieren?
Google DNS ist doch schon verboten!

Außerdem wurden im Syslog die Alarme durch meine Routing-Tabelle reduziert.

backslash hat geschrieben: ↑10 Jul 2019, 11:56 Also, wenn du die Alarme sehen willst, dann darfst du auch nicht meckern, wenn sie kommen

Leider kommen nur Alarme via UDP. Alarme via TCP z.B. durch "sipvicious" werden nicht protokolliert.
(Habe ich per Capture "zufällig" an der WAN-Schnittstelle festgestellt)

Ich würde mir noch mehr Alarme wünschen.

backslash · Beitrag von **backslash** » 12 Jul 2019, 12:24

Hi plumpsack,

Hast du dir überhaupt einmal die Mühe gemacht, dir die Routing-Tabellen anzugucken?

a) du weisst schin, was TL/DR heißt
b) wozu sollte ich... du hast Adressen per Sperr-Route gefiltert und wunderst dich, daß das IDS Alarm schlögt, wenn Pakete von den Adressen kommen... Da ist einfach nur "works as configured"... fertig

Google DNS ist doch schon verboten!

Das darfs du ja auch gerne per Sperr-Route ausfiltern. Von dort wird auch nichts unangefordertes kommen und somit auch keinen unerwünschten Alarm auslösen.

Gruß
Backlsash

Das war meine jetzt letzte Antwort auf diesen Thread.

plumpsack · Beitrag von **plumpsack** » 13 Jul 2019, 21:30

backslash hat geschrieben: ↑12 Jul 2019, 12:24 a) du weisst schin, was TL/DR heißt

Nein, klär uns bitte auf.

backslash hat geschrieben: ↑12 Jul 2019, 12:24 b) wozu sollte ich... du hast Adressen per Sperr-Route gefiltert und wunderst dich, daß das IDS Alarm schlögt, wenn Pakete von den Adressen kommen... Da ist einfach nur "works as configured"... fertig

Wie gesagt, das ist ein Bug.

Google DNS ist doch schon verboten!

backslash hat geschrieben: ↑12 Jul 2019, 12:24 Das darfs du ja auch gerne per Sperr-Route ausfiltern. Von dort wird auch nichts unangefordertes kommen und somit auch keinen unerwünschten Alarm auslösen.

Warum sollten von Google auch Attacken kommen?

backslash hat geschrieben: ↑12 Jul 2019, 12:24 Das war meine jetzt letzte Antwort auf diesen Thread.

Danke!

So, vielleicht interessiert es ja jemand der Ahnung hat.

Zur Info:

https://www.lancom-systems.de/docs/LCOS ... 67180.html

Alarm Hierunter werden alle Meldungen zusammengefasst, die der erhöhten Aufmerksamkeit des Administrators bedürfen. PANIC, ALERT, CRIT

https://www.lancom-systems.de/docs/conf ... 67180.html

Alert This category includes all messages requiring the system administrator's close attention. PANIC, ALERT, CRIT

So, und wenn so ein Administrator den Alarmen erhöhte Aufmerksamkeit widmet, feststellt das die IP-Adressen, sogar ganze Netzwerke "bullshit" sind, da niemand diese IP-Adressen oder Netzwerke benötigt, da kommst du und kannst den Fehler nicht feststellen?

Hallo?

Niemand benötigt diese Hackernetzwerke aus dem Syslog!

Du hast dir nicht einmal die Mühe gemacht die IP-Adressen/Netzwerke aus dem Syslog gegenzuprüfen!

Anbei die neue Routing-Tabelle mit blockierten Netzwerken.

Wer Telekom Deutschland benötigt, einfach die Zeilen löschen.

Ansonsten, vor und nach einem Backup/Speicherung als Skript darauf achten, was bei

Code: Alles auswählen

cd /Setup/IP-Router/IP-Routing-Table

unten steht

Code: Alles auswählen

add  255.255.255.255  0.0.0.0          0        "INTERNET"        0         on          Yes      "Diese Route wurde durch den Internet-Assistenten erzeugt"

ansonsten muss dann halt die Zeile durch die aus dem Backup ersetzt werden.

Ich bleibe dabei, das ist ein Bug!

plumpsack · Beitrag von **plumpsack** » 29 Jul 2019, 17:41

Aufgrund aktueller Meldungen in den Medien hier eine aktualisierte Routing-Tabelle (Sperr-Liste).

Ich verstehe zwar nicht was die von mir wollten, ich bin kein DAX-Unternehmen, aber schön zu sehen das man sich auf Lancom verlassen kann und alles brav im Syslog stand.

Somit konnte ich die Netzwerke herausfinden, die ich eh nicht benötige, und dann sperren.

Sicher ist sicher

sokl · Beitrag von **sokl** » 10 Sep 2020, 11:12

Hallo,

Danke für deine schöne Liste.
Es ?fehlen? 4 Nullen bei "block CN Chinanet 222.64.120.0/22" Zeil 541. Soll das so, oder wurde die Datei verändert?

MFG

plumpsack · Beitrag von **plumpsack** » 13 Sep 2020, 16:06

@sokl

Danke für deinen Hinweis.

Code: Alles auswählen

add  222.64.120.0     255.255.252.0    0        "0.0.0.0"         0         No          Yes      "block CN Chinanet 222.64.120.0/22"

stand bei mir noch in der Routing-Tablelle.

Laut:

Code: Alles auswählen

https://ipinfo.io/

gehört "222.64.120.0" zu "222.64.0.0/16"

-->

Code: Alles auswählen

add  222.64.0.0     255.255.0.0    0        "0.0.0.0"         0         No          Yes      "block CN Chinanet 222.64.0.0/16"

Habe das aktualisiert.

Danke nochmals für deinen Hinweis

LANCOM-Forum.de

R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?

Re: R883VAW - "intruder detection" nach Neuverbindung, muss das so sein?