IDS und iOS Devices

[alexw]

Hallo an alle,

ich hoffe jemand hat eine Idee, die mir hilft bei einem Problem weiter zu kommen, zu dem mir bisher einfach keine Lösung einfällt..
Das Problem ist, dass immer wenn sich ein iOS Device ins WLAN Netz (externer AP, nicht Lancom) einbucht, springt früher oder später die IDS der Firewall des Lancom an.
Der Log sieht so aus:

Code: Alles auswählen

[Firewall] 2015/12/16 15:14:13,300
Packet matched rule intruder detection
DstIP: 192.168.0.10, SrcIP: 192.168.0.10, Len: 44, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 16403, SrcPort: 16403

Filter info: packet received from invalid interface UNITYMEDIA
block source address for 10 minutes
packet rejected

[Firewall] 2015/12/16 15:14:13,304
Packet matched rule intruder detection
DstIP: 192.168.0.10, SrcIP: 192.168.0.10, Len: 44, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 16403, SrcPort: 16403

Filter info: packet received from invalid interface UNITYMEDIA
block source address for 10 minutes
packet rejected

Das wiederholt sich ein paar Mal und durch die Sperre ist das Gerät natürlich erst einmal vom Netz getrennt.

Was ich nicht nachvollziehen kann.. wieso sagt mir der Lancom "interface UNITYMEDIA", bei DstIP und SrcIP "192.168.0.10"?

Code: Alles auswählen

/Setup/IP-Router/Firewall/IDS-Aktion "%A %Hm10"

Routing Tabelle:

Code: Alles auswählen

#    IP-Adresse       IP-Netzmaske     Rtg-Tag  Peer-oder-IP      Distanz   Maskierung  Aktiv    Kommentar                                                       
#    -----------------------------------------------------------------------------------------------------------------------------------------------------------------
192.168.100.1    255.255.255.255  0       {Peer-oder-IP}  "UNITYMEDIA"     {Distanz}  0        {Maskierung}  Intranet   {Aktiv}  ja      {Kommentar}  "CATV Modem"
192.168.0.0      255.255.0.0      0       {Peer-oder-IP}  "0.0.0.0"        {Distanz}  0        {Maskierung}  nein       {Aktiv}  ja      {Kommentar}  "block private networks: 192.168.x.y"
172.16.0.0       255.240.0.0      0       {Peer-oder-IP}  "0.0.0.0"        {Distanz}  0        {Maskierung}  nein       {Aktiv}  ja      {Kommentar}  "block private networks: 172.16-31.x.y"
10.0.0.0         255.0.0.0        0       {Peer-oder-IP}  "0.0.0.0"        {Distanz}  0        {Maskierung}  nein       {Aktiv}  ja      {Kommentar}  "block private network: 10.x.y.z"
224.0.0.0        224.0.0.0        0       {Peer-oder-IP}  "0.0.0.0"        {Distanz}  0        {Maskierung}  nein       {Aktiv}  ja      {Kommentar}  "block multicasts: 224-255.x.y.z"
255.255.255.255  0.0.0.0          0       {Peer-oder-IP}  "UNITYMEDIA"     {Distanz}  0        {Maskierung}  Ein        {Aktiv}  ja      {Kommentar}  ""

Was aus der Konfig ist noch interessant?

Ich danke euch schon einmal für die Antworten.

Gruß,
Alex

[backslash]

Hi alexw,

das Problem ist hier, daß die kaputte Apple-Anwendung (hier geht es offenbar um ein Video-Chat-Programm) versucht, sich von innen auf der öffentlichen IP des LANCOMs mit den gemappten Ports anzusprechen... Das führt am Ende zu der komischen IDS-Meldung...

Das sollte ab 9.10.0471 gefixt sein...

- wieso sagt mir der Lancom "interface UNITYMEDIA", bei DstIP und SrcIP "192.168.0.10"?

Weil das ursprüngliche Paket von innen kam und an die Öffentliche IP des LANCOMs und den gemappten Port ging. Das Paket wurde daraufhin "demaskiert" und wird wieder an die interne IP und den internen Port weitergeleitet - aber so, als würde es aus dem Internet empfangen (und von daher darf es nicht kommen). Das liegt letztendlich an dem kaputten Verhalten der Applikation...

Code: Alles auswählen

- wieso wird die Sperre aktiviert, obwohl die IDS wiefolgt konfiguriert ist (%A und nicht %D):

nun ja es ist mitnichten "%D" konfiguriert, sondern "%Hm10"... Wenn der Hiost gesperrt werden soll, beibt nichts anderes übrig, als die Pakete zu verwerfen...

Und da aufgrund der kaputten Applikation nun die interne IP deines PCs gesperrt ist, kommst du nicht mehr ins Ineternet.

Und hier kann ich immer wieder nur sagen: Port- und Hostsperren finden nur die selbsternannten Experten diverser Computerzeitschriften gut, weil sie einfach keine Ahnung haben... Port- und Hostsperren führen am Ende erst zu einem erfolgreichen DoS-Angriff - wie du hier selbst erlebt hast...

Ach ja: auch aktives Ping-Blocking oder Stealth-Modus bedeuten nicht, daß dort niemand wäre... Es zeigt vielmehr mit einem roten blinkenden Pfeil auf jemanden, der ein ganz großes Schild hochhält, auf dem steht "Ätsch, ihr könnt mich nicht sehen"... (nur leider sieht ihn doch jeder)

Wäre da wirklich niemand, so würde schon der Router vorher ein ICMP "host unreachable" zurückschicken...

Gruß
Backslash

[alexw]

Hallo \,

Das sollte ab 9.10.0471 gefixt sein...

Vielen Dank für den Hinweis, da der Lancom ein 1722 ist, bleibe ich leider auf der 9.00 stehen. Ich denke der Fix wird es nicht mehr in diese Version packen

Weil das ursprüngliche Paket von innen kam und an die Öffentliche IP des LANCOMs und den gemappten Port ging. Das Paket wurde daraufhin "demaskiert" und wird wieder an die interne IP und den internen Port weitergeleitet - aber so, als würde es aus dem Internet empfangen (und von daher darf es nicht kommen). Das liegt letztendlich an dem kaputten Verhalten der Applikation...

Ok, wenn ich das richtig verstehe, will der Lancom das Paket über das WAN verschicken? Aber wieso, wenn dest eine interne IP ist? Der Lancom weiss doch, dass 192.168.0.0/255.255.255.0 im LAN liegt. Was denke ich hier falsch?

nun ja es ist mitnichten "%D" konfiguriert, sondern "%Hm10"... Wenn der Hiost gesperrt werden soll, beibt nichts anderes übrig, als die Pakete zu verwerfen...

Ja, das ist mir selbst nach meinem Post auch gekommen, deswegen habe ich meine Nachricht editiert und diesen Teil entfernt Aber den IDS und DOS Teil der Firewall zu deaktivieren ist eigentlich nicht mein Ziel, nur weil Apple rumspammen muss. Aber wohl meine einzige Lösung im Moment?

Und hier kann ich immer wieder nur sagen: Port- und Hostsperren finden nur die selbsternannten Experten diverser Computerzeitschriften gut, weil sie einfach keine Ahnung haben... Port- und Hostsperren führen am Ende erst zu einem erfolgreichen DoS-Angriff - wie du hier selbst erlebt hast...

Soll heissen du bist kein Fan der DoS und IDS Regeln?

Wäre da wirklich niemand, so würde schon der Router vorher ein ICMP "host unreachable" zurückschicken...

Schon klar

[backslash]

Hi alexw,

Vielen Dank für den Hinweis, da der Lancom ein 1722 ist, bleibe ich leider auf der 9.00 stehen. Ich denke der Fix wird es nicht mehr in diese Version packen

eher unwahrscheinlich...

Ok, wenn ich das richtig verstehe, will der Lancom das Paket über das WAN verschicken? Aber wieso, wenn dest eine interne IP ist? Der Lancom weiss doch, dass 192.168.0.0/255.255.255.0 im LAN liegt. Was denke ich hier falsch?

Ursprünglich war die Ziel-IP die WAN-IP des LANCOMs... Daher wurde das Paket quasi auf das Loopback-Interface gesendet und ein Empfang des Pakets vom WAN simuliert. Das Paket wurde an die Demaskierung weitergeleitet und da der Zielport des Pakets auch dem gemappten Quellport entsprach, war die Demaskierung erfolgreich und in dem Paket wurden Ziel-Adresse und Zielport durch das ersetzt, was die Maskierung gespeichert hat. Ergebnis: Quell und Zieladresse sind gleich und ebenfalls Quell- und Zielport. Pakete mit gleicher Quell- und Zieladresse werden vom IDS gefangen ("LAND"-Angriff).

Aber den IDS und DOS Teil der Firewall zu deaktivieren ist eigentlich nicht mein Ziel, nur weil Apple rumspammen muss. Aber wohl meine einzige Lösung im Moment?/quote]
ein einfaches "%D" reicht doch vollkommen als IDS-Aktion. Nur die Sperre solltest du entfernen, da diese letztendlich dazu geführt hat, daß das IDS deinen PC vom Internet abgeklemmt hat...

Soll heissen du bist kein Fan der DoS und IDS Regeln?

Doch, das schon - nur nicht von Host- und Port-Sperren, da genau diese Sperren einen DoS-Angriff erst erfolgreich machen... Stell dir einfach mal vor, jemand fakt bei einem Anriff die IP-Adresse des DNS-Servers deines Providers und schaft es das IDS anschlagen zu lassen... Das Ende wirst du dir sicherlich selbst ausmalen können...

Sobald der eigentliche Angriff vorbei ist, gibt es schlichtweg keinen Grund irgendwelche Pakete prophylaktisch zu sperren...

Gruß
Backslash