GeoIP Block/Portscan in core 136

Wie kann man das Konfigurieren?
Post Reply
imbio
Posts: 66
Joined: March 10th, 2011, 7:22 pm
Location: Bonn

GeoIP Block/Portscan in core 136

Post by imbio » October 17th, 2019, 6:07 am

Hallo ihr Lieben!

Ich hatte mal eine Frage zu einer Beobachtung meinerseits bezüglich des "neuen" GeoIP Blocks im core 136:

Als zusätzliche Info: Der GeoIP Block meines IPFire lässt nur IP Adressen aus Deutschland durch.

Vor einigen Wochen hatte ich schon einmal das Problem, dass ich sehr viele Treffer eines Portscanns aus dem 45.136.109/110.xxx Netz hatte, der sich am GeoIP vorbeschmuggeln konnte weil die Herkunft für die IPFire unbekannt war (Flagge mit Fragezeichen). Dieses Problem konnte ich im core 135 durch ein Umstellen der Firewalloptionen auf "REJECT" beheben.

Nach dem Update auf 136 ist dieser Portscanner wieder da und wird als IP-Adresse aus Deutschland erkannt (was meiner bescheidenen Einschätzung nach nicht sein kann) und trifft wieder auf die Firewall.

Meine Frage wären:

Ist das ein Fehler in der Datenbank, dass dieses Netz als Herkunft Deutschland auswirft?

und:

Hat vielleicht jemand eine Idee wie ich das Problem mit dem SCanner (wieder) beheben kann - Firewall in Modus "Blocked" ist schon auf "REJECTED"

Vielen Dank schon einmal im Vorraus und viele Grüße!
Image

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8522
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: GeoIP Block/Portscan in core 136

Post by Arne.F » October 17th, 2019, 8:16 am

Der GeoIP Block selbst ist in core136 nicht verändert worden. Verändert wurde nur das die Zuordnung der Fahnen im WebIF jetzt auf der gleichen Datenbasis erfolgt wie der eigentliche GeoIP Block selbst. (Daher wurde der Traffic im Log als "unbekannt" angezeigt.)

Ob du den Traffic mit Reject oder Drop behandelst macht kaum unterschiede wenn das ein Portscan ist.

Reject hilft nur wenn das eigentlich kein Portscan ist sondern ein normaler client ist, der mit einem System kommunizieren möchte was die IP vorher hatte. Mit drop wird er es weiter länger versuchen da er keine Rückmeldung bekommt.

nach maxmind und auch http://geoiplookup.net/ kommt das Netz 45.136.109/110.xxx
aus Deutschland (Comtrade LLC)

Auch laut Ripe sind das Deutsche IP's:
https://apps.db.ripe.net/db-web-ui/#/qu ... ource=RIPE
Aber der Provider agiert auch in Russland...
https://www.ripe.net/membership/indices ... trade.html
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

imbio
Posts: 66
Joined: March 10th, 2011, 7:22 pm
Location: Bonn

Re: GeoIP Block/Portscan in core 136

Post by imbio » October 17th, 2019, 10:22 am

Hallo Arne,

hab vielen Dank für deine schnelle Antwort! Okay dann war die Einschätzung meinerseits falsch - aber vielen Dank für die Links - die werde ich in Zukunft benutzen.

Also ich denke nicht, dass das normale Clients sind (siehe Anhang - Gesamttreffer von gestern) - klar da kommt keiner durch, aber die Logs werden schon sehr unübersichtlich bei den ganzen Treffern die die verursachen.

Mich hatte es damals einfach nur gewundert, als ich die Forwardoption von DROP auf REJECTED umgestellt hatte, konnte man über einen Zeitraum von ca. 2 Stunden richtig beobachten wie die Anfragen auf dem Netz zurückgegangen sind bis sie schließlich gar nicht mehr auf die Firewall getroffen sind.

Gibts denn eine Möglichkeit diese Anfragen wieder loszuwerden oder ist das etwas womit man im Zweifel leben muss?
Attachments
portscan.JPG
Image

imbio
Posts: 66
Joined: March 10th, 2011, 7:22 pm
Location: Bonn

Re: GeoIP Block/Portscan in core 136

Post by imbio » October 21st, 2019, 7:26 am

Guten Morgen,

hat bezüglich dem Ausperren solcher Anfragen (bevor diese auf die Firewall treffen) vielleicht jemand doch eine Idee?

besonders die Adresse 45.136.109.215 sticht gerade hervor. Diese kam am Freitag neu hinzu mit 933 Anfragen am Tag - am Samstag/Sonntag waren es schon über 6000. Seid 0 Uhr heute morgen sind´s schon über 2000 - also werden es vermutlich noch mehr werden. Die ganzen andren IP Adressen aus dem Netz sind im Schnitt mit ca. 900 Anfragen/Tag konstant geblieben.
Image

AlSimmons
Posts: 2
Joined: October 11th, 2009, 11:20 am

Re: GeoIP Block/Portscan in core 136

Post by AlSimmons » November 11th, 2019, 10:20 am

Hallo zusammen,

dies habe ich in den letzten Wochen auch bei meinem Anschluss beobachtet.
Anfangs hab ich fleißig Gardian mit den ip's gefüttert um diese nicht mehr in den Firewall log zu sehen.
Da Guardian einen Timeout für diese blocks hat musste ich dies öfters wiederholen.

Dann hab ich ein subnetz mit hilfe eines Subnetzrechners ermittelt.
Anschliessend konnte ich durch erstellen eines Netzes in den Firewall Groups und erstellen einer Firewall Regel diese entgültig aus den Logs verbannen.
comtrad_network.JPG
In Firewall Groups unter Networks:

Name: comtrade.msk.ru
Network address: 45.136.108.0
Netmask: 255.255.252.0
Remark: multi host portscan not blocked by GeoIP


Weiter in Firewall Rules eine neue regel erstellen:

Source
Networks: comtrade.msk.ru

Destination
Firewall:RED

Protocol:ALL
Action:DROP

Remark habe ich weggelassen da der Netzwerk Name aussagegräftig genug war.

Da diese IP's nicht mehr so häufig auftauchten und diese regel bereits gelöscht wurde, habe ich diese vorgehensweise eben schnell rekonstruiert.
Nur für den fall das diese vorgehensweise in eurem Fall nicht ausreicht sprich subnetz oder Firewall Regel fehlerhaft sein sollten.

Ich hoffe dennoch, das diese vorgehensweise hilfreich sein wird.

PS: Firewall sollte nicht im Modus "REJECT" betrieben werden, da sonst eine Antwort an die Source Address gesendet wird.

Gruß

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8522
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: GeoIP Block/Portscan in core 136

Post by Arne.F » November 11th, 2019, 3:18 pm

PS: Firewall sollte nicht im Modus "REJECT" betrieben werden, da sonst eine Antwort an die Source Address gesendet wird.
Das macht für den Angreifer keinen wirklichen unterschied. Bei einer nicht verwendeten IP kriegt er ein "IGMP not Reachable" Packet vom letzten Router vor deinem System daher weis er auch wenn man keine Antwort sendet, das der Host existiert.

Vor allem bei Dynamischen IP's kann die Verbindung auch von einem legitimen Clients kommen kann der den vorherigen Nutzer der sucht. Der andere Peer kriegt bei "DROP" nicht mit was schiefgeht und versucht es immer weiter, bei "REJECT" gibt er sofort auf.

Auch einige Portscanner höhren bei "REJECT" eher auf da "DROP" ja auch einfach ein verlorenes Packet sein kann.

Daher ist die empfohlene Einstellung "REJECT" und nicht "DROP"
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

Post Reply