Warum support.paloaltonetworks.com in Singapur als geolocated angezeigt wird ( SG )
17363
Created On 01/28/21 18:19 PM - Last Modified 03/26/21 18:59 PM
Question
was kann getan werden, wenn support.paloaltonetworks.com mit einem ( ) in Singapur auflöst GEO IP SG und es einen IP Geo-Block für SG
Environment
Jede Umgebung, die durch ein Palo geht und Firewall versucht, das Customer Support Portal ( CSP ) zu erreichen, support.paloaltonetworks.com, die lösungsmittel nach Singapur mit einem GEO IP Block für SG .
Answer
Palo Alto hat den IP Prolexic-Schutzdienst von Akamai für alle Server des Customer Service Portals am 08.01.2021 aktiviert, um Angriffe zu DDOS verhindern.
Prolexic stellt globale Datenreinigungsstationen bereit, an denen Datenverkehr analysiert und bösartiger Datenverkehr (DDoS, bekannte Schwachstellen und Exploits) entfernt wird.
Um den Datenverkehr von diesen Reinigungsstationen zuzulassen, sollten Kunden die IPs 103.41.68.129 zu den Zulassungslisten auf ihren Firewalls hinzufügen.
Diese Adresse wurde kürzlich mit einer falschen Geolocation von Singapur markiert. Akamai hat dies korrigiert, aber es kann einige Tage dauern, bis sich diese Informationen auf andere Geolocation-Anbieter ausgebreitet haben.
Unser Engineering-Team wandte sich an Akamai und sie bestätigten, dass Akamai vor kurzem die Geo-Location aktualisiert IP hat, da Singapur gezeigt wurde, als Beweise darauf hindeuteten, dass dieser Datenverkehr viel näher endete.
Der IP Adressraum ist anycast-Datenverkehr, der von Akamai Prolexic geleitet wird.Dies ist ortsloser Verkehr und wird über die optimale Route basierend auf dem Verbindungsort geliefert.
Akamai verfügt über mehrere Waschzentren in der US .Wenn die IP Verbindungsadresse US basiert, sollte erwartet werden, dass die Adresse innerhalb der beendet US wird.
In anderen geografischen Regionen sehen Sie, wie der Verkehr das optimale Land für diese Verkehrszufuhr wählt.
Es wurde beobachtet, dass einige der anderen Netzwerkanbieter-Hops in den Routen auch ungenau von Geolocation-Diensten von Drittanbietern getaggt wurden.
Akamai veröffentlicht ihre IP Geolocation-Daten in einem Feed gemäß RFC 8805.
Dies ist öffentlich und verbrauchsfähig durch Geolocation-Dienste von Drittanbietern, um eine bessere Genauigkeit ihrer Dienste zu gewährleisten.
https://ipgeo.akamai.com/akamai-geofeed.csv
Akamai hat die Entscheidung für tag ihren Anycast-Verkehr als Akamai-Hauptquartier in Cambridge Massachusetts getroffen.
Dies entspricht dem, was andere große Anbieter tun, und soll dazu beitragen, die Inkonsistenz in Geolocation-Diensten von Drittanbietern für Datenverkehr zu beheben, der standortloser jeder Cast-Datenverkehr ist.
PaloAltos Drittanbieter-Dienst für GeoIP hat bestätigt, dass sie diese Änderung in ihren Datenbanken am Dienstag, den 9. Februar 2021 vornehmen werden. Andere Geo-Anbieter von IP Drittanbietern können je nach Aktualisierungszeitplänen mehr oder weniger Zeit in Anspruch nehmen.
Wie in diesem TraceRt zu sehen ist, sind der Hopfen und die Ping-Zeiten zu kurz, um Singapur zu sein.
Dieser Test wurde von einem Computer nicht im Palo Alto-Netzwerk, sondern hinter einem Palo ausgeführt Firewall .
C . . WINDOWS > support.paloaltonetworks.com
Rückverfolgungsroute nach support.paloaltonetworks.com [103.41.68.129] über maximal
30 Hops:
1 2 ms 1 ms 1 ms 192.168.0.1
2 15 ms 11 ms 12 ms 142.254.131.189
3 36 ms 30 ms 22 ms tge0-0-8.mckntxwf01h.texas.rr.com [24.28.88.145]
4 16 ms 22 ms 23 ms agg23.plantxmp01r.texas.rr.com [24.175.49.225]
5 12 ms 15 ms 14 ms agg27.crtntxjt01r.texas.rr.com [24.175.36.177]
6 14 ms 14 ms 14 ms agg21.dllatxl301r.texas.rr.com [24.175.49.0]
7 14 ms 11 ms 13 ms bu-ether24.dllstx976iw-bcr00.tbone.rr.com [66.109.6.52]
8 12 ms 14 ms 11 ms 209-18-43-77.dfw10.tbone.rr.com [209.18.43.77] 9 * *
* Timeout-Anforderung.
10 45 ms 43 ms 41 ms ae2.cs1.dfw2.us.zip.zayo.com [64.125.26.202]
11 * 50 ms 49 ms ae3.cs1.lax112.us.eth.zayo.com [64.125.29.53]
12 43 ms 48 ms 43 ms ae13.mpr1.lax12.us.zip.zayo.com [64.125 .28.231]
13 44 ms 46 ms 46 ms 128.177.68.30
14 47 ms 44 ms 48 ms po110.bs-a.sech-lax.netarch.akamai.com [23.57.96.243]
15 * * * Timeout der Anforderung.
16 47 ms 44 ms 44 ms ae120.access-a.sech-lax.netarch.akamai.com [23.57.96.249]
17 51 ms 43 ms 43 ms 103.41.68.129
Trace complete.
