liste von IP-Adressen blocken

[averlon]

Ich habe eine Linux-Maschine laufen auf der fail2ban installiert ist.

fail2ban kann man eine liste von IP-Adressen mitgeben, die dann blockiert werden. Die Liste kann auch im laufenden Betrieb aktualisiert werden.

Siehe auch:
http://www.blocklist.de/en/index.html
und dann die Liste: https://lists.blocklist.de/lists/all.txt

Ich erhalte dauernd Meldungen im Log von:

Code: Alles auswählen

PACKET_INFO: Dst: <IPv4-Adresse des lancom>:5060 {F42240ro}, Src: 47.91.29.207:15152 (UDP): connection refused

Manuell könnte ich jetzt alle diese IP-Adressen in eine FW-Regel einbauen.

Ich suche allerdings einen Weg in dem das z.B. über eine Liste erfolgen könnte:

Code: Alles auswählen

5.100.249.24,IL
51.75.133.20,FR
146.88.241.214,US
185.94.111.1,RU
103.174.130.13,IN
64.62.156.73,US
154.213.184.20,NL
146.88.241.164,US
80.94.93.188,GB
162.142.125.251,US
103.75.180.159,VN
159.226.17.60,CN
159.226.17.60,CN ZZ
47.236.125.30,US
47.236.202.159,US
164.90.177.139,US
185.180.198.27,US
156.238.99.93,IN
143.198.221.225,US
193.222.99.50,DE
193.222.99.50,DE GB
198.235.24.70,US
93.123.85.148,GB
185.197.251.50,DE
188.187.61.156,RU
167.94.138.151,US
8.222.158.125,SG
8.222.158.125,SG ZZ
47.91.29.207,US
47.91.29.207,US JP
64.62.197.90,US
103.173.15.100,IN
162.217.96.21,US

Eine Antwort kann ich schon vorwegnehmen: ja, "connection refused" zeigt ja, dass die Verbindung nicht zustande gekommen ist.

Soweit ich das verstehe, bekommt der Absender das aber mit. Ich würde in der FW gerne einen "drop" machen. Nach meiner Information wird das dann dem Absender nicht mitgeteilt, sondern das Paket wird einfach vom lancom nicht beantwortet. Das müsste beim Absender so aussehen, als ob die IP-Adresse gerade nicht aktiv ist.

Ich habe ein Skript geschrieben, das das logfile nach diesen Meldungen scannt und via whois versucht herauszufinden aus welchen Ländern die Anfragen kommen. Bestimmte Länder würde ich dann blocken wollen. Wohl wissend, dass sich jeder auch einen Rechner in einem anderen Land besorgen kann. Vielleicht würde ich das evtl. auch abhängig machen vom Port der angefragt wird.

Gäbe es eine Möglichkeit eine Liste den lancom 1906VA mitzugeben?

[plumpsack]

Nutz doch den Lancom-Router als DNS-Sinkhole- und Black Hole Router.

Device ist 0.0.0.0

Geht für DNS per DNS-Filter und/oder auch IP-Adresse bzw. Subnetzwerke in der Routingtabelle.

Wobei einzelne IP-Adressen zu sperren macht keinen Sinn, da die Netze eh unterwandert sind.

Selbst die US-Amerikaner haben das jetzt, zu ihren eigenen Netzen, zugegeben.

Siehe hierzu Meldungen zu AT&T, Verizon, T-Mobile (US) und Co. ...

Die Seelenhändler, ehm IP-Adress-Händler, bzw. TELCOs haben den Überblick total verloren.

An abuse@, an die Inhaber der IP-Adressen, zu schreiben kannst du in den meisten Fällen vergessen.

Haftung gibt es für die wohl auch nicht.

Das BSI sagt, " ... jeder ist für seine IT-Sicherheit selber verantwortlich ..."

Also, sperr den Mist, den du nicht benötigst.

zur Info:

DNS-Sinkhole
https://de.wikipedia.org/wiki/DNS-Sinkhole

Black Hole Router
https://de.wikipedia.org/wiki/Black_Hole_Router

"Als Black-Hole-Router wird ein Router bezeichnet, der IP-Pakete, die zum Weiterversand fragmentiert werden müssten, ohne Rückmeldung verwirft."

"Ein Router, der keine Antwort schickt, sondern das Paket stillschweigend verwirft, wird Black-Hole-Router genannt."

[averlon]

Nutz doch den Lancom-Router als DNS-Sinkhole- und Black Hole Router.

Danke für die Information.

Die große Frage in diesem Forum, wie eigentlich in allen Foren ist: Wie?

Wenn du mir da mit Bezug auf den lancom noch helfen würdest dann wäre deine Information für mich nutzbar.
Danke

[backslash]

Hi averlon,

Soweit ich das verstehe, bekommt der Absender das aber mit. Ich würde in der FW gerne einen "drop" machen. Nach meiner Information wird das dann dem Absender nicht mitgeteilt, sondern das Paket wird einfach vom lancom nicht beantwortet. Das müsste beim Absender so aussehen, als ob die IP-Adresse gerade nicht aktiv ist.

nun ja, auch wenn das LANCOM nicht antworetet, bekommt der Absender das mit... Keine Antwort heißt nämlich nicht, daß da niemand wäre, sondern ist roter blinkender Pfeil auf jemanden, der sagt, "du kannst mich nicht sehen". Wäre da wirklich niemand, dann würder der Router davor ein ICMP Host/Network unreachable zurückschicken.

Du kannst aber gerne den Stealth-Mode aktivieren - es ist halt nur Schlangenöl und bringt keinerlei Sicherheitsgewinn... (es ist eher andersherum: durch das "Verstecken" wirst du erst recht interessant)

BTW: connection refused kommt dann, wenn ein Paket an das LANCOM gerichtet war und es keinen Lister für das Paket gibt

Gruß
Backslash

[plumpsack]

Du kannst aber gerne den Stealth-Mode aktivieren - es ist halt nur Schlangenöl und bringt keinerlei Sicherheitsgewinn... (es ist eher andersherum: durch das "Verstecken" wirst du erst recht interessant)

Was hat der "Stealth-Mode" mit den Sperrouten bzw. Nullrouten zutun?


Willst du jetzt sagen, das wenn der "Stealth-Mode" NICHT aktiv ist, dann kommen keine Zugriffsversuche mehr?

Sitzt eine IP-Adresse, bzw. ein Subnetz auf Sperroute, also auf 0.0.0.0, werden die Pakete alle verworfen.

Routen mit dem Eintrag '0.0.0.0' für Router bezeichnen Ausschluss- bzw. Sperr-Routen. Datenpakete für diese
„Null-Routen“ werden verworfen und nicht weitergeleitet.

Was soll da passieren?

Habe ich das etwas verpasst?

BTW: connection refused kommt dann, wenn ein Paket an das LANCOM gerichtet war und es keinen Lister für das Paket gibt

Ach und woher weißt du, das die Anfrage an den Router und nicht doch an einen offenen Port eines OS im Netz gehen sollte?

[plumpsack]

Danke für die Information.

Die große Frage in diesem Forum, wie eigentlich in allen Foren ist: Wie?

MA_LCOS-1072-Reference-Manual_DE.pdf

6.2.4.2 Routing-Tabellen für IPv4 / IPv6

Seite 380

Router

Routen mit dem Eintrag '0.0.0.0' für Router bezeichnen Ausschluss- bzw. Sperr-Routen. Datenpakete für diese
„Null-Routen“ werden verworfen und nicht weitergeleitet.

MA_LCOS-1080-Reference-Manual_DE.pdf

6.2.4.2 Routing-Tabellen für IPv4 / IPv6

Seite 384

Router

Routen mit dem Eintrag '0.0.0.0' für Router bezeichnen Ausschluss- bzw. Sperr-Routen. Datenpakete für diese
„Null-Routen“ werden verworfen und nicht weitergeleitet.

Ich hoffe das hilft ...

[averlon]

@plumpsack: Danke für die Hilfestellung.

Wenn ich das richtig verstehe, müsste ich dann einen Eintrag in der Routing-Tabelle pro IP-Adresse erstellen, die ich blockieren möchte.
Mal unabhängig davon, ob der Vorgang überhaupt Sinn macht.

Nachdem es wohl keine Möglichkeit gibt, dass der Lancom die Daten selbst aus einer Liste zieht, müsste ich dann aus meinem Skript heraus die entsprechenden Einträge wohl via SSH-Verbindung über die ClI in den Router bringen.

Doppelte Einträge würden zwar vermutlich nicht stören, wären aber auch nicht schön.

Da werde ich mich mal dran setzen, rein aus Interesse, ob ich das hinbekommen werde. Ob ich das dann produktiv einsetzen werden - eher nicht - aber "basteln" werden ich mal daran!

Danke für die Information.

[backslash]

Hi averlon,

hör nicht auf plumpsack - der hat keine Ahnung...

Die "connection refused" kommen dann - und genau nur dann, wenn ein Paket an das LANCOM gerichtet war und es keinen Listener gibt. In Abhängigkeit der Einstellung des Stealth-Mode schickt das LANCOM daraufhin ein ICMP-Port-Unreachable/TCP-Reset (Stealth-Mode aus) zurück oder verwirft das Paket still (Stealth-Mode ein).

Wenn es einen Listener gibt, dann behandelt der Listener das Paket und das LANCOM antwortet - so der Zugriff zulässig ist. Die Zulässigkeit wird über /Setup/Config/Access-Table gesteuert. Ist der Zugriff unzulässig greift wieder die Einstellung des Stealth-Mode

Wenn das Paket an einen weitergeleiteten Port gerichtet ist, dann läuft es durch die Firewall in der es bei einer Deny-All-Strategie auch einen entsprechende Allow-Regel geben muß, damit das Paket weitergeleitet wird. In der Deny-All-Regel kannst du dann sagen, ob soche Pakete gedroppt werden solen (Aktion DROP), oder ob ein ICMP-Port-Unreachable/TCP-Reset zurückgeschickt werden soll (Aktion REJECT).

Wen das Paket an einen durch das NAT geöffneten Port gerichtet ist und keine Antwort ist, hast du hoffentlich auch eine Deny-All-Regel um das abzublocken (ansonsten geht das Paket nämlich durch! Ein NAT ersetzt keine Firewall!)...

Solange du aber "connection refused" siehst, mußt du dir um die Filterung der Adressen keine Gedanken machen - vor allem mußt du keine Filterlisten mit irgendwelchen Adressen aus China oder Rußland oder von wer weiß woher einpflegen - das ist alles nur Schlangenöl

Und in der Routing-Tabelle sind Sperr-Routen zu den "bösen" Adressen erst recht wertfrei... Es sein denn dein, Netz wäre bereits von Malware infiziert und du würdest darüber versuchen, den Zugriff der Trojaner auf ihre C&C-Server zu blocken. Dann ist es aber ehrlich gesagt, schon längst zu spät...

Gruß
Backslash

[averlon]

Hallo @backslash

danke für die Details.

Listener habe ich bei WAN nur über VPN.

VPN mit Zertifikaten - sollte also auch einigermaßen sauber sein.

Ich bin ja nur ein "Bastler" und will in meiner freien Zeit als Rentner auch noch was lernen. Steckt nur Hobby (früher beruflich) dahinter, kein produktiver Einsatz z.B. für eine Firma o.d.gl. .

Danke für deine Zeit!

[plumpsack]

hör nicht auf plumpsack - der hat keine Ahnung...

- das ist alles nur Schlangenöl

Und warum bietet Lancom nur all dieses "Schlangenöl" an?

[PappaBaer]

Moin,

@plumpsack
Auch wenn es leider vermutlich vergebene Lebensmüh' ist, versuche ich mal, Dir ein Beispiel für den Sinn und Zweck von Sperr- oder Blackhole-Routen zu geben:

Angenommen Du hast am Router A sowohl directly connected ein paar IP-Subnetze aus dem Bereich 192.168.0.0/16 und Dein Router lernt parallel dazu über ein Routing-Protokoll dynamisch Routen zu weiteren Subnetzen aus 192.168.0.0/16, die über weitere Hops (Router B, C usw. oder VPN-Tunnel) bei Dir im Netz erreichbar sind (ja, es gibt tatsächlich Netzwerke bei Firmen, die ein wenig größer sind).
Fallen nun die Wege zu den weiteren Hops oder diese selber aus, dann merkt das Routing-Protokoll das. Wenn es nun dynamisch keine weiteren anderen Wege gibt, dann gibt es in Deiner Routing-Tabelle zu diesem Netz auch keine Route mehr. In dem Fall wird Deine Default-Route matchen und der Router A schickt das Paket (das ja eigentlich intern über weitere Router zugestellt werden sollte) über diese raus.
Wenn Deine Default-Route nun genattet Richtung Internet geht, wird der erste ISP-Router das Paket verwerfen (da Pakete mit einer RFC1918-Ziel-Adresse im öffentlichen Netz nicht geroutet werden). Du würdest also ggf. den ISP-Router zwingen eine Menge Pakete verwerfen zu müssen.
Wenn Du nun aber sogar Deine Default-Route ungenattet auf einen weiteren Router X, an dem der Internet-Breakout erfolgt, zeigt und in diesem Router X die "Rück"-Routen zu Deinen Netzen hinter Router A der Einfachheit halber als Summery-Route "192-168.0.0/16 -> Router A" zusammengefasst sind, dann käme es in diesem Fall zu Routing-Loops.
Beides kann mit dem Einsatz einer Sperr-Router "192.168.0.0/16 -> 0.0.0.0" auf Router A verhindert werden.
Das ganze ist im übrigen Hersteller unabhängig zu sehen.

Ich bleibe dabei: Der Sinn und Zweck dieser Sperr-Routen ist nicht, dass Du Deine Routingtabelle in diesem Maße als Feature Deines Sicherheitskonzeptes nutzt. Aber das Thema hatten wir bei Dir ja schon öfter.

Was den Stealth-Mode betrifft, so meine ich mich erinnern zu können, dass Backslash mal erwähnt hat, dass es diesen nur gibt, da ein Projekt-Kunde mit entsprechend hohem Auftragsvolumen diesen haben wollte. Den Sinn bzw. Unsinn diesen Modus hat Backslash ausreichend beschrieben. Nicht jedes Feature ist automatisch sinnvoll und empfehlenswert, nur weil es dieses gibt.

Grüße,
Torsten

[plumpsack]

Ich bleibe dabei: Der Sinn und Zweck dieser Sperr-Routen ist nicht, dass Du Deine Routingtabelle in diesem Maße als Feature Deines Sicherheitskonzeptes nutzt.

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

Ich bleibe dabei.

Seitdem keine DDoS attacks mehr.

[5624]

Seitdem keine DDoS attacks mehr.

Naja, ein paar Portscans als DDoS-Attacken zu bewerten ist schon mehr als lebensfremd. Empfehle Nachschulung oder Behandlung.

PS: nur weil die Portscans nicht mehr gemeldet/geloggt werden, heißt nicht, dass diese nicht da sind. Du hättest auch das Logging herunterdrehen können für das gleiche Ergebnis.

[plumpsack]

Naja, ein paar Portscans als DDoS-Attacken zu bewerten ist schon mehr als lebensfremd.

Naja, wenn im Syslog steht: "(TCP): denial of service attack"

gehe ich mal von einem DDoS aus ...

Vielleicht lese ich das auch nur falsch ...

Empfehle Nachschulung oder Behandlung.

Für bzw. gegen was?

[averlon]

Immerhin hat mich die Diskussion dazu gebracht ein kleines Perl-Skript zu schreiben, mit dem ich via SSH auf den lancom zugreifen kann und dann über die CLI verschiedene Dinge, quasi im Batch, durchführen kann. War nicht ganz einfach und hat mich einige Nerven gekostet, funktioniert aber jetzt.

Vermutlich werde ich es nie brauchen - aber war wieder eine gute neue Erfahrung!

Frohe Weihnachten!