Portscans verhindern mit eigener DROP-Regel

[cheese_grater]

Hallo zusammen.

Ich habe das Problem, das bestimmte IPs aus bestimmten Netzen ständig Portscans auf meinen Anschluß triggern, teilweise mehrfach am Tag. Der 1793VA ist so konfiguriert, daß automatisch Zieladresse- und -Port gesperrt werden und die Verbindung recycelt wird. Finde ich auch sinnvoll so.

Nun dachte ich aber, schlau wie ich bin, daß ich sämtliche Netze in ein Stationsobjekt zusammenfasse und diese als DROP-Regel in die Firewall aufnehme, um es gar nicht erst zu einem Portscan kommen zu lassen - funktioniert aber nicht, denn immer noch kommen IPs aus diesen Netzen dazu einen Portscan zu triggern.

Hierbei ist es unerheblich, ob die Regel als höchste (weitere Regeln beachten) oder niedrigste Prio konfiguriert ist.

Wäre toll, wenn mir jemand dabei zur Hand gehen könnte meinen Fehler zu korrigieren.

Vielen Dank!

[backslash]

Hi cheese_grater

Code: Alles auswählen

der 1793VA ist so konfiguriert, daß automatisch Zieladresse- und -Port gesperrt werden und die Verbindung recycelt wird. Finde ich auch sinnvoll so.

das ist ganau das, was du tunlichst nicht machen solltest... Denn genau dadurch wird ein DOS-Angriff erst erfolgkreich - auch wenn die selbsternannten Experten diverser Computerzeitschriften das als Sicherheitsfeature ansehen.

Ein Portscan ist erstmal ungefährlich - er wird nur zu einem Problem, wenn er auf offene Ports trifft, über die auch tatsächlich eine Schwachstelle erreicbar ist. Daher ist es sinnvoller in der Firewall eine DENY-ALL Regel aufzusetzen und nur das freizuschalten, was auch wirklich genutzt werden soll. Wenn du dann keine Serverdienste anbietest, dann meldet der Portscan auch keine offenen Ports - solange du auch im LANCOM alle Konfigurationsmögklichkeiten aus dem WAN verboten hast, was aber die Default-Eintstellung ist.

Desweiteren blockt das LANCOM nach einem erkannten Portscan alle weiteren Zugriffe von der jeweilgen Quelladresse - solange der Portscan läuft und als Aktion "zurückweisen" gewählt ist. Daher gibt es auch keine Möglichkeit die Portscan-Erkennung explizit über eine Regel abzuschalten. Es gibt nur die Möglichkeit, die Aktion zu definieren, die bei einer Erkennung ausgeführt wird.

Gruß
Backslash

[cheese_grater]

Hallo Backslash.

Danke für Deine Antwort.

das ist ganau das, was du tunlichst nicht machen solltest... Denn genau dadurch wird ein DOS-Angriff erst erfolgkreich - auch wenn die selbsternannten Experten diverser Computerzeitschriften das als Sicherheitsfeature ansehen.

Du hast völlig Recht. Man denkt einfach nicht mehr darüber nach, aber Deine Darstellung ist absolut sinnig und überzeugend. Danke!

Hab's ausgeschaltet und den Schwellenwert halbiert. Wir sehen, wie's läuft. Interessanterweise laufen die meisten Scans auf Ports im 14.000er Bereich; keine Ahnung, warum.

Ein Portscan ist erstmal ungefährlich - er wird nur zu einem Problem, wenn er auf offene Ports trifft, über die auch tatsächlich eine Schwachstelle erreicbar ist. Daher ist es sinnvoller in der Firewall eine DENY-ALL Regel aufzusetzen und nur das freizuschalten, was auch wirklich genutzt werden soll. Wenn du dann keine Serverdienste anbietest, dann meldet der Portscan auch keine offenen Ports - solange du auch im LANCOM alle Konfigurationsmögklichkeiten aus dem WAN verboten hast, was aber die Default-Eintstellung ist.

Serverdienste werden keine angeboten. Was aber die Deny-All-Regel betrifft, so scheue ich davor noch ein wenig zurück, da mir momentan nicht klar ist, auf welche Art von Paketen sich das beziehen würde, nur SYNs, oder auch SYN/ACK und ACK? Du siehst, bei mir besteht Nachholbedarf.

Desweiteren blockt das LANCOM nach einem erkannten Portscan alle weiteren Zugriffe von der jeweilgen Quelladresse - solange der Portscan läuft und als Aktion "zurückweisen" gewählt ist. Daher gibt es auch keine Möglichkeit die Portscan-Erkennung explizit über eine Regel abzuschalten. Es gibt nur die Möglichkeit, die Aktion zu definieren, die bei einer Erkennung ausgeführt wird.

Die Firewall ist wirklich eine Sache für sich, und mir schwant, daß ich mir da noch einiges an Wissen (gibt's irgendwo Tutos?) draufschaffen muß.

Ich habe also keine direkte Möglichkeit Netze davon abzuhalten mein Gerät zu kontaktieren - es sei denn ich definiere die Deny-All-Regel und schalte sukzessive alles frei?

Danke nochmal, backslash!

[alf29]

Moin,

Ich habe also keine direkte Möglichkeit Netze davon abzuhalten mein Gerät zu kontaktieren -

Nein, das könnte nur Dein Provider verhindern, daß die Pakete aus diesen Netzen bei Deinem Router ankommen...um einen Vergleich zu bringen: Du hast draußen an Deinem Haus eine Klingel neben der Tür. Wenn die da ist, kannst Du nicht verhindern, daß beliebige Leute bei Dir klingeln, außer Du montierst die Klingel ab, aber dann kann eben niemand mehr bei Dir klingeln. Also läßt Du die Klingel dran, und schaust, wer da vor der Tür steht, bevor Du sie aufmachst...und wenn Du die Klingel abstellst, weil zu viele Staubsaugervertreter kommen, dann hörst Du den Postboten auch nicht mehr...

Viele Grüße

Alfred

[cheese_grater]

Hallo Alfred.

Danke für Deine Antwort.

Nein, das könnte nur Dein Provider verhindern, daß die Pakete aus diesen Netzen bei Deinem Router ankommen...um einen Vergleich zu bringen: Du hast draußen an Deinem Haus eine Klingel neben der Tür. Wenn die da ist, kannst Du nicht verhindern, daß beliebige Leute bei Dir klingeln, außer Du montierst die Klingel ab, aber dann kann eben niemand mehr bei Dir klingeln. Also läßt Du die Klingel dran, und schaust, wer da vor der Tür steht, bevor Du sie aufmachst...und wenn Du die Klingel abstellst, weil zu viele Staubsaugervertreter kommen, dann hörst Du den Postboten auch nicht mehr...

Hau mich blau, aber ich meine mich zu erinnern, daß ich, Anfang der 90er, hinter meinem 784kb-DSL-Anschluß eine Linux-Kiste laufen hatte, mit IPTables-Firewall.

Und der konnte ich, meine ich, beibringen, daß IPs aus gewissen Bereichen gefälligst zu ignorieren seien. War, glaube ich, UUNet geschuldet. Komischer Laden, damals. Vorgänger war doch irgendwas mit 'M' im Namen ....

Aber, mit fast 60, mag Einen das Erinnerungsvermögen auch trüben. Ich versuche mich in die Lancom-Technik einzulesen und danke Dir nochmals für Deine Antwort.

Liebe Grüße.

[backslash]

Hi cheese_grater,

Hau mich blau, aber ich meine mich zu erinnern, daß ich, Anfang der 90er, hinter meinem 784kb-DSL-Anschluß eine Linux-Kiste laufen hatte, mit IPTables-Firewall.

Und der konnte ich, meine ich, beibringen, daß IPs aus gewissen Bereichen gefälligst zu ignorieren seien.

ein PC ist auch etwas anderes als ein Router... Auf einem PC können beliebeige Dienste angeboten werden, weshalb da auch eine feingranulare Inbound-Regelsatz notwendig ist. Ein Router bietet aber nur eine Hand voll Diensten an, die an oder abgeschaltet werden und selbst wissen wer sie kontaktieren darf und wer nicht - anhand ihrer Konfiguration, z.B. wenn der DHCP-Server im INTRANET an und der DMZ aus ist, dann ignoriert er Anfragen aus der DMZ..

Daher gibt es in der IPv4-Firewall keinen expliziten Inbound-Regelsatz - die IPv6-Firewall hingegen hat zwar auch einen expliziten Inbound-Regelsatz, aber auch bei ihr läßt sich die Portscan-Erkennung nicht per Regel deaktivieren.

Gruß
Backslash

[plumpsack]

China-Mann/Frau/Diverse macht Portscan - Kein Firewalleintrag!

202.96.99.85

Im Syslog sehe ich das schon. Die armen AVM-Fritz-Box-Benutzer, die sehen nichts!

whois 202.96.99.85

Manche Leute bezeichnen das hier ja als "Hintergrundrauschen" ...
Auch wenn Botntze immer wieder auf den gleichen lokalen Port zugreifen.

Ist halt "Hintergrundrauschen" ...

Code: Alles auswählen

2020-09-20 05:00:10	LOCAL3	Alarm	Dst: meine_IP:44818 {router}, Src: 202.96.99.85:25126 (UDP): connection refused
2020-09-20 04:58:50	LOCAL3	Alarm	Dst: meine_IP:20547 {router}, Src: 202.96.99.85:55931 (UDP): connection refused
2020-09-20 04:57:12	LOCAL3	Alarm	Dst: meine_IP:9600 {router}, Src: 202.96.99.84:4736 (UDP): connection refused
2020-09-20 04:55:53	LOCAL3	Alarm	Dst: meine_IP:9160 {router}, Src: 202.96.99.84:54727 (UDP): connection refused
2020-09-20 04:54:33	LOCAL3	Alarm	Dst: meine_IP:8123 {router}, Src: 202.96.99.84:53102 (UDP): connection refused
2020-09-20 04:52:55	LOCAL3	Alarm	Dst: meine_IP:8080 {router}, Src: 202.96.99.85:32772 (UDP): connection refused
2020-09-20 04:50:58	LOCAL3	Alarm	Dst: meine_IP:8000 {router}, Src: 202.96.99.85:52690 (UDP): connection refused
2020-09-20 04:49:20	LOCAL3	Alarm	Dst: meine_IP:6001 {router}, Src: 202.96.99.84:19810 (UDP): connection refused
2020-09-20 04:48:00	LOCAL3	Alarm	Dst: meine_IP:5900 {router}, Src: 202.96.99.84:10455 (UDP): connection refused
2020-09-20 04:46:41	LOCAL3	Alarm	Dst: meine_IP:5432 {router}, Src: 202.96.99.84:58324 (UDP): connection refused
2020-09-20 04:45:21	LOCAL3	Alarm	Dst: meine_IP:5222 {router}, Src: 202.96.99.84:4601 (UDP): connection refused
2020-09-20 04:43:21	LOCAL3	Alarm	Dst: meine_IP:3460 {router}, Src: 202.96.99.84:17246 (UDP): connection refused
2020-09-20 04:42:01	LOCAL3	Alarm	Dst: meine_IP:3306 {router}, Src: 202.96.99.84:4966 (UDP): connection refused
2020-09-20 04:40:42	LOCAL3	Alarm	Dst: meine_IP:3128 {router}, Src: 202.96.99.84:7639 (UDP): connection refused
2020-09-20 04:39:03	LOCAL3	Alarm	Dst: meine_IP:2123 {router}, Src: 202.96.99.85:10019 (UDP): connection refused
2020-09-20 04:37:44	LOCAL3	Alarm	Dst: meine_IP:1962 {router}, Src: 202.96.99.85:22021 (UDP): connection refused
2020-09-20 04:36:25	LOCAL3	Alarm	Dst: meine_IP:1900 {router}, Src: 202.96.99.85:17092 (UDP): connection refused
2020-09-20 04:35:05	LOCAL3	Alarm	Dst: meine_IP:1720 {router}, Src: 202.96.99.85:33965 (UDP): connection refused
2020-09-20 04:33:45	LOCAL3	Alarm	Dst: meine_IP:1521 {router}, Src: 202.96.99.85:13797 (UDP): connection refused
2020-09-20 04:31:45	LOCAL3	Alarm	Dst: meine_IP:1194 {router}, Src: 202.96.99.85:5312 (UDP): connection refused
2020-09-20 04:30:26	LOCAL3	Alarm	Dst: meine_IP:1080 {router}, Src: 202.96.99.85:42434 (UDP): connection refused
2020-09-20 04:28:30	LOCAL3	Alarm	Dst: meine_IP:993 {router}, Src: 202.96.99.85:37955 (UDP): connection refused
2020-09-20 04:26:33	LOCAL3	Alarm	Dst: meine_IP:902 {router}, Src: 202.96.99.85:49507 (UDP): connection refused
2020-09-20 04:25:13	LOCAL3	Alarm	Dst: meine_IP:808 {router}, Src: 202.96.99.85:39427 (UDP): connection refused
2020-09-20 04:23:16	LOCAL3	Alarm	Dst: meine_IP:631 {router}, Src: 202.96.99.85:39487 (UDP): connection refused
2020-09-20 04:21:17	LOCAL3	Alarm	Dst: meine_IP:523 {router}, Src: 202.96.99.85:62667 (UDP): connection refused
2020-09-20 04:19:18	LOCAL3	Alarm	Dst: meine_IP:502 {router}, Src: 202.96.99.85:48109 (UDP): connection refused
2020-09-20 04:17:21	LOCAL3	Alarm	Dst: meine_IP:445 {router}, Src: 202.96.99.85:39333 (UDP): connection refused
2020-09-20 04:15:42	LOCAL3	Alarm	Dst: meine_IP:389 {router}, Src: 202.96.99.84:55970 (UDP): connection refused
2020-09-20 04:14:23	LOCAL3	Alarm	Dst: meine_IP:177 {router}, Src: 202.96.99.84:27541 (UDP): connection refused
2020-09-20 04:12:24	LOCAL3	Alarm	Dst: meine_IP:143 {router}, Src: 202.96.99.84:21475 (UDP): connection refused
2020-09-20 04:10:05	LOCAL3	Alarm	Dst: meine_IP:111 {router}, Src: 202.96.99.85:32619 (UDP): connection refused
2020-09-20 04:08:45	LOCAL3	Alarm	Dst: meine_IP:102 {router}, Src: 202.96.99.85:24017 (UDP): connection refused
2020-09-20 04:07:25	LOCAL3	Alarm	Dst: meine_IP:80 {router}, Src: 202.96.99.85:24401 (UDP): connection refused
2020-09-20 04:06:08	LOCAL3	Alarm	Dst: meine_IP:70 {router}, Src: 202.96.99.85:25163 (UDP): connection refused
2020-09-20 04:04:49	LOCAL3	Alarm	Dst: meine_IP:53 {router}, Src: 202.96.99.85:30900 (UDP): connection refused
2020-09-20 04:02:50	LOCAL3	Alarm	Dst: meine_IP:37 {router}, Src: 202.96.99.85:53745 (UDP): connection refused
2020-09-20 04:01:31	LOCAL3	Alarm	Dst: meine_IP:23 {router}, Src: 202.96.99.85:42747 (UDP): connection refused
2020-09-20 04:00:11	LOCAL3	Alarm	Dst: meine_IP:21 {router}, Src: 202.96.99.85:12680 (UDP): connection refused

Was kann man dagegen unternehmen?

In der Routing-Tabelle einfach das Netzwerk blockieren.

Es bringt nichts abuse@... oder antispam@... anzuschreiben, da die z.T. diese Netzwerke selbst verwalten und wissen für was diese Netzwerke im Einsatz sind!

Wenn du mit China nichts am Hut hast, blockier China!

Zu deinem PC.

Jeder gute "Mailserver" bietet dir drop IP, drop Network oder drop Domain.

Keine Ahnung warum Lancom sich damit so schwer tut externe IP- oder auch Domain-Anfragen einfach zu droppen.

[GrandDixence]

Wenn keine Serverdienste freigeschaltet wurden:

- IPv4: Port Forwarding
- IPv6: entsprechende Firewallregel für eingehenden Netzwerkverkehr => expliziter Inbound-Regelsatz
- IPv4+IPv6: explizite Freischaltung von internen Dienste des LANCOM-Routers

wird bei korrekter Konfiguration der SPI-Firewall:

- DENY_ALL-Firewallregel => Protokolle:=ANY Quelle:=ANY Ziel:=ANY Aktion:=DROP Aktiv:=An
- TCP-Stealth-Modus (siehe LCOS-Referenzhandbuch)
- Fragmentierte IP-Datenpakete "reassemblieren" (siehe LCOS-Referenzhandbuch und LCOS-Menühandbuch)
- Firewall beachtet für SIP-Pakete Reject-Regeln (LCOS-Menübaum > Setup > Sip-alg > Firewall-ueberstimmen:=nein)

ein Portscan mit DROP abgewiesen.
https://de.wikipedia.org/wiki/Stateful_ ... Inspection

https://de.wikipedia.org/wiki/Firewall-Regelwerk

Ob sich die neue oder umkonfigurierte Firewall korrekt+wunschgemäss bei einem Portscan verhaltet, sollte mit dem Heise-Portscan+Wireshark kontrolliert werden:
https://www.heise.de/security/dienste/p ... ?scanart=1

viewtopic.php?f=31&t=17621&p=99943#p99943

Soll ein Serverdienst von aussen erreichbar sein, sollte dieser aus Sicherheitsgründen mit einem VPN-Tunnel geschützt werden:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

Wer die Arbeitsweise einer SPI-Firewall "live" beobachten möchte, sollte die Verbindungsliste beobachten (LCOS-Menübaum/Status/IP-Router/Verbindungsliste):
fragen-zum-thema-firewall-f15/firewall- ... ml#p109378

fragen-zum-thema-ipv6-f46/geloest-ausse ... ml#p104122

Weitere Sicherheitshinweise findet man unter:
fragen-zum-thema-firewall-f15/schulnetz ... ml#p106924

[GrandDixence]

In der Routing-Tabelle einfach das Netzwerk blockieren.

Das solche Sperrlisten in der Routing-Tabelle keine gute Idee sind, wurde unter:
fragen-zum-thema-firewall-f15/countrybl ... 11147.html
ausführlich erklärt und unter:
fragen-zum-thema-firewall-f15/nicht-dir ... 18374.html
eindrücklich bewiesen!

[plumpsack]

In der Routing-Tabelle einfach das Netzwerk blockieren.

Das solche Sperrlisten in der Routing-Tabelle keine gute Idee sind, wurde unter:
...
eindrücklich bewiesen!

Wurde es halt nicht!

Außerdem gibt es bis heute keine Doku von Lancom, nicht R&S die mit IP-Tables arbeiten, wie man eingehende Netzwerke verbietet.

Der Router soll die Anfragen der Netzwerke/IP-Adressen sofort droppen!

Such mal nach
"lancom block incoming network"
"lancom drop incoming network"
"lancom block incoming IP"
"lancom drop incoming IP"
...

Habe ich da in den Dokus von Lancom etwas überlesen?

[GrandDixence]

Habe ich da in den Dokus von Lancom etwas überlesen?

Ja, Kapitel "Stateful-Packet-Inspection" im LCOS-Referenzhandbuch nicht gelesen und nicht verstanden! Dieses Kapitel im LCOS-Referenzhandbuch beschreibt die Funktionsweise einer SPI-Firewall.
https://www.lancom-systems.de/docs/LCOS ... 63023.html

Soll ein Serverdienst von aussen erreichbar sein, sollte dieser aus Sicherheitsgründen mit einem VPN-Tunnel geschützt werden:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795