HTTP-Weiterleitungen nach *amazonaws* werden geblockt

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
van Grunz
Beiträge: 51
Registriert: 16 Feb 2007, 09:36

HTTP-Weiterleitungen nach *amazonaws* werden geblockt

Beitrag von van Grunz »

Hallo,

folgendes Szenario:
Smart-TV an LAN4 eines 1793VA mit aktuellster Firmware (10.40.0166RC3), VLAN-ID 4

Auf dem Smart-TV soll Netflix (und nur das) geschaut werden dürfen.

Folgende Regeln sind definiert:
1. SMART-TV_DNS
Prio: 55
Aktionen: Übertragen; SNMP
Verbindungs-Quelle: Objekt SMART-TV
Verbindungs-Ziel: 8.8.8.8,146.185.167.43,<IP des Routers im Smart-TV-Netz>
Protokolle/Quell-Dienste: alle
Protokolle/Ziel-Dienste: DNS

2. SMART-TV_NETFLIX_HTTP
Prio: 54
Aktionen: Übertragen; SNMP
Verbindungs-Quelle: Objekt SMART-TV
Verbindungs-Ziel: NETFLIX&AMAZON
Protokolle/Quell-Dienste: alle
Protokolle/Ziel-Dienste: HTTP

3. SMART-TV_NETFLIX_HTTPS
Prio: 53
Aktionen: Übertragen; SNMP
Verbindungs-Quelle: Objekt SMART-TV
Verbindungs-Ziel: NETFLIX&AMAZON
Protokolle/Quell-Dienste: alle
Protokolle/Ziel-Dienste: HTTPS

4. SMART-TV_BLOCK
Prio: 50
Aktionen: Zurückweisen; SNMP
Verbindungs-Quelle: Objekt SMART-TV
Verbindungs-Ziel: alle
Protokolle/Quell-Dienste: alle
Protokolle/Ziel-Dienste: alle

Als DNS-Ziel "NETFLIX&AMAZON" sind zwei Listen zusammengefaßt:
1. die bereits mitgelieferte NETFLIX-Liste
2. ein selbst gemachtes DNS-Ziel mit dem Ausdruck: *.amazonaws.com

Im IP-Router unter N:N-Mapping habe ich die DNS-Adressen von Google & SecureDNS über die Gegenstelle INTERNET mit der Netzmaske 255.255.255.0 auf die Gateway-Adresse des Routers (.1) gemappt, damit diese DNS-Server nicht anders auflösen als der Router selbst.

Im Firewall-Log stelle ich fest, daß ausschließlich die DNS-Anfragen sowie HTTPS-Protokolle sauber übertragen werden. Sämtliche Anfragen über HTTP werden geblockt, obwohl ich bei einer Reverse-DNS-Anfrage *.amazonaws.com der jeweiligen IPs erhalte.

Dementsprechend habe ich Lücken in der Filmliste.

Ohne das N:N-Mapping sind die Lücken deutlich größer, und es wird wesentlich mehr geblockt.

Aber auch in der HTTPS-Regel wird hin & wieder etwas geblockt, was nicht hätte geblockt werden dürfen, beispielsweise eine Adresse nach *.nflxvideo.net, die in der eingebauten Regel bereits vorhanden ist (*nflxvideo*).

Kann mir jemand erklären, warum das so ist, und ob eine Abhilfe möglich ist?
Dem ersten Anschein nach arbeitet die Firewall nicht sauber und blockt eher zuviel als zu wenig. Irritierend ist, daß besonders die HTTP-Regel komplett ignoriert zu werden scheint.

Noch eine andere Frage am Rande:
Wie kann ich feststellen, daß die Umleitung von 8.8.8.8 (Google-DNS) zu meinem Router erfolgreich ist? Ich kann via tracert nach wie vor den echten Server feststellen, der ja mit der Router-IP ersetzt werden sollte.
ittk
Beiträge: 1244
Registriert: 27 Apr 2006, 09:56

Re: HTTP-Weiterleitungen nach *amazonaws* werden geblockt

Beitrag von ittk »

Ohne passende Traces vom Fehlerfall wird das nichts :D
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
Benutzeravatar
van Grunz
Beiträge: 51
Registriert: 16 Feb 2007, 09:36

Re: HTTP-Weiterleitungen nach *amazonaws* werden geblockt

Beitrag von van Grunz »

Wo soll ich das Trace hinladen? Hier als Beitrag klappt es nicht, zuviele Zeichen.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: HTTP-Weiterleitungen nach *amazonaws* werden geblockt

Beitrag von backslash »

Hi van Grunz,

du hatst hier gleich mehrere Fehler...
  • damit du DNS-Ziele in der Firewall nutzen kannst *MUSS* das LANCOM der DNS-Server in deinem Netz sein - also auch für dein IPTV.
  • das N:N-NAT paßt *NUR* die *QUELL* Adresse an (bei abgehenden Paketen). Damit kannst du den Google-DNS-Server nicht auf das LANCOM "umlenken".
daher:
  • die Regel SMART-TV_DNS darf als Ziel nur die IP des LANCOMs enthalten - alle anderen IPs müssen aus ihr entfernt werden.
  • das N:N-NAT kannst du auch einfach entfernen - es greift eh nicht.
Im Firewall-Log stelle ich fest, daß ausschließlich die DNS-Anfragen sowie HTTPS-Protokolle sauber übertragen werden. Sämtliche Anfragen über HTTP werden geblockt
das kann ich mir gelinde gesagt nicht vorstellen - es sei denn du hättest einen Fehler in der Regeldefinition. Gib doch mal "show filter" im CLI ein und schau ob aus allen Regeln Filter angelegt wurden. Statt zwei getrennte Regeln anzulegen, kannst du SMART-TV_NETFLIX_HTTP und SMART-TV_NETFLIX_HTTPS auch du zu einer einzigen Regel zusammenfassen, indem du als Zieldienst einfach "WEB" nimmst (oder halt HTTP und HTTPS zusammen)
Aber auch in der HTTPS-Regel wird hin & wieder etwas geblockt, was nicht hätte geblockt werden dürfen, beispielsweise eine Adresse nach *.nflxvideo.net, die in der eingebauten Regel bereits vorhanden ist (*nflxvideo*).
Kann mir jemand erklären, warum das so ist, und ob eine Abhilfe möglich ist?
vermutlich weil der Client nicht das LANCOM als DNS-Server verwendet hat. Die Firewall kann nur die DNS-Namen nutzen, die von den Clients auch angefragt wurden - unter Nutzung des LANCOMs als DNS-Server. Die Firewall selbst fragt keine Namen an - kann sie auch nicht, denn sie kennt ja nur die Wildcardlisten. Eben diese Wildcardlisten sind auch der Grund, weshalb das LANCOM der DNS-Server im Netz sein muß. Die Firewall muß *alle* DNS-Anfragen (bzw. die Antworten) sehen, um sie mit der Wildcardliste abgleichen zu können. Sobald ein Host also nicht das LANCOM als DNS-Server nutzt, funktionieren die DNS-Ziele nicht.

Ein weiteres Problem könnten Clients sein, die DNS-Anfragen länger cachen, als ihnen der DNS-Server vorgibt (Stichwort TTL). Daher gibt es ab der 10.40 die "DNS-Minimum-Cache-Time" (im CLI unter "/Setup/Firewall") mit einem Default von 3 Minuten. Wenn dein Smart-TV länger cacht, dann mußt du den Wert passend erhöhen...
Wie kann ich feststellen, daß die Umleitung von 8.8.8.8 (Google-DNS) zu meinem Router erfolgreich ist
gar nicht, weil das nicht passiert...

Gruß
Backslash
Benutzeravatar
van Grunz
Beiträge: 51
Registriert: 16 Feb 2007, 09:36

Re: HTTP-Weiterleitungen nach *amazonaws* werden geblockt

Beitrag von van Grunz »

backslash hat geschrieben: 25 Mär 2020, 13:17du hatst hier gleich mehrere Fehler...
Hui...danke schonmal für die Aufklärung. :D
  • damit du DNS-Ziele in der Firewall nutzen kannst *MUSS* das LANCOM der DNS-Server in deinem Netz sein - also auch für dein IPTV.
  • das N:N-NAT paßt *NUR* die *QUELL* Adresse an (bei abgehenden Paketen). Damit kannst du den Google-DNS-Server nicht auf das LANCOM "umlenken".
Das habe ich mir schon gedacht.
daher:
  • die Regel SMART-TV_DNS darf als Ziel nur die IP des LANCOMs enthalten - alle anderen IPs müssen aus ihr entfernt werden.
  • das N:N-NAT kannst du auch einfach entfernen - es greift eh nicht.
Habe ich schon vor ner guten Stunde erledigt, weil ich das Gefühl hatte, daß es sowieso nichts bringt. N:N-NAT ist gelöscht, und als einziges valides Ziel für DNS-Anfragen steht der Router im 192.168.77er-Netz. Logischerweise verenden dann sämtliche Anfragen an den Google-Server 8.8.8.8 sowie SecureDNS 146.185.167.43. Die Zuweisung per DHCP klappt einwandfrei, der Smart-TV steht auf Automatik.
Im Firewall-Log stelle ich fest, daß ausschließlich die DNS-Anfragen sowie HTTPS-Protokolle sauber übertragen werden. Sämtliche Anfragen über HTTP werden geblockt
das kann ich mir gelinde gesagt nicht vorstellen - es sei denn du hättest einen Fehler in der Regeldefinition. Gib doch mal "show filter" im CLI ein und schau ob aus allen Regeln Filter angelegt wurden.
Das sieht (verkürzt) so aus:

Code: Alles auswählen

Filter 00000003 from Rule SMART-TV_DNS:
  Protocol: 17
  Src: 192.168.77.0/24 0-0 (LAN ifc SMART-TV)
  Dst: 192.168.77.1/32 53-53
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000004 from Rule SMART-TV_DNS:
  Protocol: 6
  Src: 192.168.77.0/24 0-0 (LAN ifc SMART-TV)
  Dst: 192.168.77.1/32 53-53
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000005 from Rule SMART-TV_NETFLIX:
  Protocol: 6
  Src: 192.168.77.0/24 0-0 (LAN ifc SMART-TV)
  Dst: NETFLIX 443-443
  <jede Menge IP-Adressen aus 45.57.*.*>
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000006 from Rule SMART-TV_NETFLIX:
  Protocol: 6
  Src: 192.168.77.0/24 0-0 (LAN ifc SMART-TV)
  Dst: NETFLIX 80-80
  <jede Menge IP-Adressen aus 45.57.*.*>
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000007 from Rule SMART-TV_AMAZONAWS:
  Protocol: 6
  Src: 192.168.77.0/24 0-0 (LAN ifc SMART-TV)
  Dst: AMAZON_ALL 443-443
         <no address available>
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000008 from Rule SMART-TV_AMAZONAWS:
  Protocol: 6
  Src: 192.168.77.0/24 0-0 (LAN ifc SMART-TV)
  Dst: AMAZON_ALL 80-80
         <no address available>
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000009 from Rule SMART-TV_BLOCK:
  Protocol: 0
  Src: 192.168.77.0/24 0-0 (LAN ifc SMART-TV)
  Dst: 0.0.0.0/0 0-0
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      reject
Statt zwei getrennte Regeln anzulegen, kannst du SMART-TV_NETFLIX_HTTP und SMART-TV_NETFLIX_HTTPS auch du zu einer einzigen Regel zusammenfassen, indem du als Zieldienst einfach "WEB" nimmst (oder halt HTTP und HTTPS zusammen)
Ich habe die Regeln nochmal umgebaut. Aktuell habe ich eine ausschließlich für Netflix (Standard-Vorgabe) und eine selbst gebaute, die nach *amazonaws* führt (nennt sich als Regelwerk SMART-TV_AMAZONAWS). HTTP & HTTPS habe ich ebenfalls zusammen geführt. Danke für den Tipp mit "WEB".

Trotzdem erscheint im Firewall-Log dann eine Meldung wie diese hier:

192.168.77.227 -> 54.76.239.85:80 -> SMART-TV_BLOCK

54.76.239.85 löst auf nach ec2-54-76-239-85.eu-west-1.compute.amazonaws.com, sollte also von SMART-TV_AMAZONAWS weitergeleitet werden.

Aber auch bei einem neueren Test (gerade nochmal Netflix gestartet, und es blieben wieder etliche Kacheln leer) sehe ich dann solche Firewall-Logs:

192.168.77.227 -> 45.57.78.147:443 (!) -> SMART-TV_BLOCK

45.57.78.147 löst auf nach ipv4_1.mce0.c018.dus002.ix.nflxvideo.net, sollte also von SMART-TV_NETFLIX weitergeleitet werden.
Aber auch in der HTTPS-Regel wird hin & wieder etwas geblockt, was nicht hätte geblockt werden dürfen, beispielsweise eine Adresse nach *.nflxvideo.net, die in der eingebauten Regel bereits vorhanden ist (*nflxvideo*).
Kann mir jemand erklären, warum das so ist, und ob eine Abhilfe möglich ist?
vermutlich weil der Client nicht das LANCOM als DNS-Server verwendet hat. Die Firewall kann nur die DNS-Namen nutzen, die von den Clients auch angefragt wurden - unter Nutzung des LANCOMs als DNS-Server. Die Firewall selbst fragt keine Namen an - kann sie auch nicht, denn sie kennt ja nur die Wildcardlisten. Eben diese Wildcardlisten sind auch der Grund, weshalb das LANCOM der DNS-Server im Netz sein muß. Die Firewall muß *alle* DNS-Anfragen (bzw. die Antworten) sehen, um sie mit der Wildcardliste abgleichen zu können. Sobald ein Host also nicht das LANCOM als DNS-Server nutzt, funktionieren die DNS-Ziele nicht.
Ein weiteres Problem könnten Clients sein, die DNS-Anfragen länger cachen, als ihnen der DNS-Server vorgibt (Stichwort TTL). Daher gibt es ab der 10.40 die "DNS-Minimum-Cache-Time" (im CLI unter "/Setup/Firewall") mit einem Default von 3 Minuten. Wenn dein Smart-TV länger cacht, dann mußt du den Wert passend erhöhen...
Ich weiß nicht, wie lange er cacht. Wenn er abgeschaltet wird, dann ist er vom Stromnetz getrennt. Normalerweise sollte der Cache dann leer sein. Da der Smart-TV aber nur noch den Router als DNS akzeptieren darf, sollten von der Seite aus keine neueren Probleme entstehen können?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: HTTP-Weiterleitungen nach *amazonaws* werden geblockt

Beitrag von backslash »

Hi van Grunz
54.76.239.85 löst auf nach ec2-54-76-239-85.eu-west-1.compute.amazonaws.com, sollte also von SMART-TV_AMAZONAWS weitergeleitet werden.
es ist völlig egal, wie eine Rückwärtsauflösung aussieht. Es kommt darauf an, was der Client angefragt hat. Und im "show filter" sieht man, daß der Client bis zu dem Zeitpunkt, als du das ausgelesen hast, keine DNS-Anfrage gestellt hat, die auf das DNS-Ziel AMAZON_ALL matcht:

Code: Alles auswählen

Filter 00000007 from Rule SMART-TV_AMAZONAWS:
  Protocol: 6
  Src: 192.168.77.0/24 0-0 (LAN ifc SMART-TV)
  Dst: AMAZON_ALL 443-443
         <no address available>
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept
entweder stimmt die Definition des DNS-Ziels nicht oder der Client fragt einen andern Namen an.

hier müßtest du dann einen DNS-Trace machen, um zu sehen, was der Client anfragt.
BTW: mit dem Trace "fw-dns" kannst du nachverfolgen, was die Firewall mit den DNS-Namen so treibt...

Ich weiß nicht, wie lange er cacht. Wenn er abgeschaltet wird, dann ist er vom Stromnetz getrennt. Normalerweise sollte der Cache dann leer sein.
sollt man von ausgehen...
Da der Smart-TV aber nur noch den Router als DNS akzeptieren darf, sollten von der Seite aus keine neueren Probleme entstehen können?
richtig...

Gruß
Backslash
Benutzeravatar
van Grunz
Beiträge: 51
Registriert: 16 Feb 2007, 09:36

Re: HTTP-Weiterleitungen nach *amazonaws* werden geblockt

Beitrag von van Grunz »

Servus backslash,
backslash hat geschrieben: 25 Mär 2020, 15:34es ist völlig egal, wie eine Rückwärtsauflösung aussieht. Es kommt darauf an, was der Client angefragt hat.
Wenn alle im Netz den selben DNS-Server verwenden, dann war mein Gedanke, daß man über eine Rückwärtssuche auf die fehlenden Einträge kommt. Anscheinend war das nicht der Fall.
Und im "show filter" sieht man, daß der Client bis zu dem Zeitpunkt, als du das ausgelesen hast, keine DNS-Anfrage gestellt hat, die auf das DNS-Ziel AMAZON_ALL matcht:

[...]

entweder stimmt die Definition des DNS-Ziels nicht oder der Client fragt einen andern Namen an.
Da ich mich erst kurz mit diesen interessanten Analysetools beschäftige, war mir das nicht aufgefallen. Die DNS-Regel mit Amazon habe ich gelöscht. Scheinbar kam die nicht von Netflix, sondern vom Smart-TV selbst, als es nach Updates suchte. Die liegen interessanter Weise in deren Wolke.
hier müßtest du dann einen DNS-Trace machen, um zu sehen, was der Client anfragt.
BTW: mit dem Trace "fw-dns" kannst du nachverfolgen, was die Firewall mit den DNS-Namen so treibt...
Bingo!

Das war das Puzzle-Teil, was mir noch gefehlt hat. Es konnte eine weitere Netflix-Namensauflösung nicht durchgeführt werden, die weder in der Standard-Regel enthalten war noch über reverse-DNS sichtbar wurde:

*nflxso*

Vielleicht mag die jemand in neuere LCOS mit einpflegen? :wink:

Zwei Tests später, und ich habe keine ungeladenen Kacheln mehr. Schaun mer mal, ob das so bleibt, sonst muß ich wieder 'ran.

Führe ich "show filter" durch, ist die IP-Liste deutlich länger geworden.

Ich bedanke mich vielmals für die Hilfe!

Bleiben Sie gesund...
Antworten