Category Archives: Technischer Blog

reCaptcha und Firewalls

reCaptcha liefert für das Frontend ein komplettes Element mit Eingabefunktion aus, plus eine Information ans Backend damit das Backend
vergleichen kann ob es korrekt ausgefüllt ist. Wenn dieser Frontend-Part fehlt (durch eine Firewall oder andere Optionen) kann das
Formular nicht erfolgreich abgesendet werden.

Gründe hierfür sind:

Lokale Richtlinien auf dem Client Computer

Das große Problem hierbei ist das ein Nutzer sehr viel „verstellen“ kann.
Ein Support ist in der Regel dann nur wirklich im direkten Kontakt möglich – und es betrifft auch nur einen bis wenige Nutzer

  • Adblock, ublock origin, Privacy Addon im BrowserDurch Filterlisten auf die gstatic.com, google.com und recaptcha.net ausschließen könnte hier schon der 1. Schritt liegen
  • Firefox RegelnFirefox hat eine Tracking Protection (about:preferences#privacy)
    Auch hier kann einiges extrem „angepasst“ werden
  • FloodingWenn z.b. der Nutzer über einen riesigen Proxy/ privates VPN zugreift und reCaptcha zu oft aufgerufen wird und Google das aus Flooding-Schutz sperrt
  • Javascript deaktiviertWenn das Endgerät z.b. auf seinem lokalen Gerät Javascript deaktiviert hat kann das Nachladen von weitere Informationen (in diesem Falle das reCaptcha-Element) nicht nachgeladen werden würde

Firewallregeln für Outgoing Policys (https/http Proxys)

(nur für den Fall das es das gesamte System betrifft und oder Gästenetz?)

Für IPv4 Adressen(*2):
dig -t TXT \_netblocks.google.com
dig -t TXT \_netblocks3.google.com

davon benötigen wir diese Blocks (gilt natürlich nur bis sich das bei
Google ändert):

ip4:172.217.0.0/19
ip4:172.217.32.0/20
ip4:172.217.128.0/19
ip4:172.217.160.0/20
ip4:172.217.192.0/19
ip4:172.253.56.0/21
ip4:172.253.112.0/20
ip4:108.177.96.0/19
ip4:35.191.0.0/16
ip4:130.211.0.0/22
ip4:35.190.247.0/24
ip4:64.233.160.0/19
ip4:66.102.0.0/20
ip4:66.249.80.0/20
ip4:72.14.192.0/18
ip4:74.125.0.0/16
ip4:108.177.8.0/21
ip4:173.194.0.0/16
ip4:209.85.128.0/17
ip4:216.58.192.0/19
ip4:216.239.32.0/19

in eine Datei speichern. Diese Datei können sie dann mit der folgenden Anleitung importieren und regelmäßig auffrischen (runterscrollen zum Interaktiven Tutorial):

Microsoft Endpoints

Allerdings schreibt google selbst (*1):
-> but you should periodically check this, as these blocks may occasionally change.
Regelmäßige Updates sind also erforderlich

(Quellen)
*1 https://code.google.com/archive/p/recaptcha/wikis/FirewallsAndRecaptcha.wiki
*2 https://chronicler.tech/firewall-considerations-for-google-recaptcha/

HOWTO – Verwendung von REGEX Suchmustern bei der Suche im Firebox System Manager

Die Suche im Traffic Monitor wird oft als schwach bezeichnet, weil hier keine “wildcards” unterstützt werden.

Diese Aussage ist jedoch schlicht falsch, da der FSM sehr wohl wildcards unterstützt, allerdings nicht die “üblichen Verdächtigen” und zudem erst nach zusätzlicher Aktivierung der Suchmuster (REGEX). Wenn man sich ein wenig eingearbeitet hat, enthält der FSM durch Vewendung der REGEX einen der leistungsfähigsten Suchfilter, die so üblicherweise zur Verfügung gestellt werden. Leider sind REGEX nicht wirklich intuitiv 🙂

Weiterlesen »

VPN-Verbindungsprobleme mit Vodafone Kabel-Routern

Wie Golem.de berichtet kommt es bei Vodafone Kabel Routern zu Problemen mit IPSec VPN Verbindungen.

Es betrifft im speziellen die Vodafone Stations.
Es gibt davon 2 Hersteller:
Arris (hier scheint VPN zu funktionieren)
und
Technicolor (hier taucht das beschriebenen Problem auf)

Vodafone arbeitet an einer Lösung durch ein neues Firmware Update – welches allerdings noch nicht verteilt wird.

Wie finde ich heraus von welchem Hersteller mein Gerät ist?
Auf der Rückseite des Gerätes steht die Kennung.
Ich habe den Arris (TG2442DE).

Bei dem Technicolor steht dort CGA4233DE.

Probleme mit DHCP Relay bei 12.5.4

aktuell kann es bei Verwendung von DCHP RELAY auf Fireware 12.5.4 zu Problemen kommen; der Dienst kann vereinzelt crashen. Dies führt dazu, dass in den verwendeten Subnetzen keine DHCP-Adressen mehr vergeben werden.

Workarounds:

  • Reboot der Firewall (startet den Dienst neu)
  • DHCP Relay im Subnetz durch lokalen DHCP-Server ersetzen.

Der Fehler ist laut Knowledgebase bereits in der 12.6.2 (noch nicht verfügbar) behoben

Quellen:

IPS Signature Update Probleme mit Firmware 12.6.x (update)

Update 2020-10-08:

Es gibt ein neues IPS_Pattern (18.114), das Problem ist gelöst.

 

Aktuell scheint es Probleme beim Download eines IPS-Signatur-Updates zu geben.

Nach unseren Tests tritt dies nur in Verbindung mit 12.6.x auf.

 

 

 

 

 

 

 

Die Signatur-Anzeige hat bereits das “neue” Format: 18.113

 

 

 

 

Auf eine Box mit 12.5.4 mit dem “alten” Format: 4.1084 funktioniert derzeit das Pattern Update problemlos.

 

 

 

 

 

 

Wir gehen davon aus, dass sich das Problem von selbst löst, sobald das nächste Pattern zur Verfügung gestellt wird.

 

 

Update aus einem CASE bei WatchGuard:

Thanks for the detailed case description! The checksum error you’re encountering with IPS downloads on 12.6+ devices is a known issue we are currently having with signature version 18.113. It has been relayed to our engineering team and we are actively working towards resolving it.

Minimum AP Firmware v8.6.0 in Fireware v12.5.4 und höher

Sollten Sie ein Upgrade Ihrer WatchGuard Firebox auf v12.5.4 oder höher planen, müssen vorab die Access Points (via Gateway Wireless Controller) mindestens auf die Firmware v8.6 oder höher aktualisiert werden.

Falls Sie das Upgrade der Firebox bereits durchgeführt haben, wechselt der AP Status permanent zwischen Online/Offline und kann daher nicht mehr verwaltet werden. Sie können ein entsprechendes Downgrade der Firebox durchführen, anschließend die Firmware der APs auf v8.6.0 oder höher upgraden und danach dann wieder die Firmware der Firebox auf v12.5.4 oder höher upgraden.

Falls Sie Ihre Access Points via Wi-Fi Cloud verwalten, können Sie die Updates unabhängig von der Firebox Firmware durchführen.

>> weitere Infos in diesem Knowledge Base Artikel

DCHP Server Probleme mit 12.6.2

Symptom:

“WLAN geht nicht mehr”

Ursache:

im VLAN wurde keine IP mehr vergeben. DHCP-Server verteilt keine IP-Adressen mehr.

Recherche:

>> Knowledge-Base-Artikel bei WatchGuard

Der DHCP-Prozess scheint sich hier mit erhöhter CPU-Last zu verklemmen und liefert keine IP-Adressen mehr aus.

Laut KB vorgeschlagener Workaround:
  • Reboot (hat in diesem Fall nur für 10-12h geholfen, danach ging es wieder los)
  • Alle DHCP Reservierungen in allen Scopes entfernen (ist hier nicht sinnvoll, da sehr intensiv mit Reservierungen gearbeitet wurde)
Verwendeter Workaround
  • Downgrade auf 12.5.4 (die Version lief vorher seit dem Upgrade stabil).