GeoIP Blocking – blokowanie ruchu na podstawie geolokalizacji IP

GeoIP Blocking to technika bezpieczeństwa polegająca na filtrowaniu ruchu sieciowego na podstawie kraju lub regionu przypisanego do adresu IP.

W najprostszym przypadku firewall otrzymuje połączenie:

Internet
   |
   v
203.0.113.50
   |
   v
GeoIP Database
   |
   v
Country: XYZ
   |
   v
Firewall Policy

i na tej podstawie decyduje:

ALLOW

albo:

DROP

GeoIP Blocking jest często stosowany jako dodatkowa warstwa ochrony, a nie jako podstawowy mechanizm bezpieczeństwa.

Jak działa GeoIP?

Adres IP jest mapowany na określoną lokalizację.

Przykład:

IP
 |
 v
198.51.100.25
 |
 v
GeoIP Database
 |
 +-- Country: Poland
 +-- Region: ...
 +-- ASN: ...

Firewall może następnie zastosować regułę:

IF country == X
THEN DROP

Przykład

Firma prowadzi działalność wyłącznie w Polsce.

Może zastosować politykę:

ALLOW:
Poland

DROP:
Other countries

Schemat:

                  INTERNET
                     |
             +-------+-------+
             |               |
          Poland          Other
             |               |
             v               v
          ALLOW             DROP

Na pierwszy rzut oka wygląda to bardzo skutecznie.

Problem polega na tym, że geolokalizacja IP nie mówi, gdzie fizycznie znajduje się człowiek.

GeoIP nie jest dokładną lokalizacją

To bardzo ważne.

GeoIP może powiedzieć:

IP → Poland

ale niekoniecznie:

IP → konkretna osoba → konkretny adres

Bazy GeoIP są tworzone na podstawie danych o adresacji IP, operatorach, ASN i innych źródłach.

Dlatego mogą występować błędy.

VPN a GeoIP Blocking

Największym problemem jest VPN.

Załóżmy:

Attacker
   |
   | VPN
   v
VPN Server - Poland
   |
   v
Your Server

Atakujący może fizycznie znajdować się zupełnie gdzie indziej.

Firewall widzi jednak:

Source Country: Poland

i przepuszcza ruch.

Proxy

Podobny problem występuje z proxy:

Attacker
   |
   v
Proxy
   |
   v
Your Server

Serwer widzi adres proxy, a nie rzeczywisty adres atakującego.

Tor

Sieć Tor również może utrudniać geolokalizację.

Client
  |
  v
Tor Network
  |
  v
Exit Node
  |
  v
Server

Firewall może widzieć tylko adres węzła wyjściowego.

Dlatego GeoIP Blocking nie powinien być traktowany jako metoda identyfikacji użytkownika.

GeoIP jako warstwa Defense in Depth

GeoIP ma największy sens jako dodatkowa warstwa:

Internet
   |
   v
Firewall
   |
   +--> GeoIP
   |
   +--> Reputation
   |
   +--> IDS/IPS
   |
   +--> Rate Limiting
   |
   v
Application

Nie powinien być jedyną ochroną.

GeoIP i firewall

Przykładowa polityka:

Source:
Internet

Destination:
Web Server

Port:
443

Country:
Blocked countries

Action:
DROP

Można też zastosować odwrotną strategię:

Allowed countries:
PL
DE
CZ
SK

a pozostały ruch odrzucać.

Whitelist vs Blacklist

To dwa podstawowe podejścia.

Blacklist

ALLOW:
All

DROP:
Country A
Country B
Country C

Zaletą jest mniejsza liczba wyjątków.

Wadą jest to, że reszta świata nadal może się łączyć.

Whitelist

ALLOW:
PL
DE
CZ

DROP:
Everything else

To znacznie bardziej restrykcyjna polityka.

Może być bardzo dobra dla usług przeznaczonych wyłącznie dla określonych regionów.

GeoIP dla panelu administracyjnego

Ciekawy przypadek:

Internet
   |
   v
Admin Panel

Jeżeli administratorzy pracują wyłącznie z określonych krajów, można ograniczyć dostęp:

PL → ALLOW
DE → ALLOW
Other → DROP

Jeszcze lepiej jednak stosować:

VPN
+
MFA
+
IP Allowlist
+
GeoIP

GeoIP samo w sobie nie powinno być główną kontrolą dostępu do panelu administracyjnego.

GeoIP dla SSH

Przykład:

Internet
   |
TCP/22
   |
GeoIP
   |
Poland → dalej
Other → DROP

Ale jeszcze lepsza architektura:

Internet
   |
VPN / Zero Trust Access
   |
SSH

Zamiast wystawiać SSH bezpośrednio do Internetu.

GeoIP i web application

Przykładowo sklep internetowy działa tylko w kilku państwach:

PL → ALLOW
DE → ALLOW
CZ → ALLOW

Other → BLOCK

Może to ograniczyć część niepotrzebnego ruchu.

GeoIP i API

API może być szczególnie interesującym przypadkiem.

Załóżmy:

Mobile App
   |
   v
API

Jeżeli API jest wykorzystywane tylko przez klientów z określonego regionu, GeoIP może być dodatkowym sygnałem.

Ale:

Nie należy używać GeoIP jako jedynego mechanizmu uwierzytelniania API.

GeoIP i brute force

Załóżmy, że panel administracyjny jest regularnie atakowany z określonych regionów.

Można zastosować:

GeoIP
+
Rate Limiting
+
MFA
+
WAF

Schemat:

Attacker
   |
   v
GeoIP
   |
Rate Limit
   |
WAF
   |
MFA
   |
Application

To jest zdecydowanie silniejsze niż samo GeoIP.

GeoIP + IDS/IPS

GeoIP może dostarczyć dodatkowy kontekst dla systemów takich jak Snort czy Suricata.

Przykład:

Connection
     |
     v
GeoIP
     |
Country: X
     |
     v
IPS Rule
     |
     +---- ALERT
     |
     +---- DROP

Można tworzyć polityki uwzględniające kraj źródłowy.

GeoIP + Zeek

Zeek może dostarczać informacje o komunikacji:

Host
 |
 +--> IP
       |
       +--> Country
       +--> ASN

Dzięki temu analityk SOC może łatwiej wyszukiwać nietypowe połączenia.

Przykład:

Workstation
   |
   +--> Poland
   +--> Germany
   +--> Netherlands
   +--> Unknown Country

Ostatnie połączenie może być interesujące, ale nie oznacza automatycznie ataku.

GeoIP + SIEM

GeoIP jest szczególnie przydatny po dodaniu danych do SIEM.

Przykład:

Firewall
   |
   v
SIEM
   |
   +-- Source IP
   +-- Country
   +-- ASN
   +-- Destination
   +-- Port
   +-- Action

Można następnie budować reguły:

IF

User normally connects from Poland

AND

successful login from unusual country

THEN

generate alert

To jest znacznie bardziej wartościowe niż proste:

Country != Poland → BLOCK

Impossible Travel

GeoIP może być jednym z elementów wykrywania tzw. impossible travel.

Przykład:

10:00
Warsaw
   |
   v
Successful Login

11:15
New York
   |
   v
Successful Login

Jeżeli użytkownik nie mógł fizycznie przemieścić się między tymi lokalizacjami w tak krótkim czasie, może to być sygnał przejęcia konta.

Oczywiście VPN, roaming i niedokładność GeoIP mogą generować false positives.

GeoIP i CDN

Trzeba uważać przy usługach korzystających z CDN.

Schemat:

User
 |
 v
CDN
 |
 v
Origin Server

Origin może zobaczyć adres infrastruktury CDN zamiast rzeczywistego klienta.

Dlatego GeoIP powinno być stosowane w odpowiednim miejscu architektury.

GeoIP i Reverse Proxy

Podobnie:

Internet
   |
Reverse Proxy
   |
Application

Jeżeli filtr GeoIP znajduje się na serwerze aplikacyjnym, trzeba prawidłowo obsługiwać przekazywanie informacji o kliencie.

Nie można bezrefleksyjnie ufać dowolnemu nagłówkowi HTTP typu:

X-Forwarded-For

Jeżeli może go ustawić sam klient.

GeoIP i IPv6

Nie wolno zapominać o IPv6.

Błąd:

IPv4 → GeoIP → BLOCK

IPv6 → brak reguły

może stworzyć obejście zabezpieczenia.

Dlatego polityka powinna obejmować:

IPv4
+
IPv6

GeoIP Database

Geolokalizacja zależy od bazy danych.

Dane mogą się zmieniać:

IP Allocation
      |
      v
ISP / ASN
      |
      v
GeoIP Database

Dlatego baza powinna być regularnie aktualizowana.

Stara baza może powodować:

• błędne blokowanie,
• błędne zezwalanie,
• nieaktualne przypisania.

Najczęstszy błąd – „zablokuję Rosję i Chiny i jestem bezpieczny”

To bardzo popularne, ale nie jest prawidłowym modelem bezpieczeństwa.

Atakujący może użyć:

VPN
Proxy
Cloud VPS
Botnet
Compromised Server
Tor

Przykład:

Attacker
   |
Compromised Server
   |
   v
Your Server

GeoIP zobaczy lokalizację serwera pośredniczącego.

GeoIP nie zastępuje:

❌ MFA

❌ WAF

❌ IDS/IPS

❌ rate limiting

❌ firewall

❌ EDR

❌ silnego uwierzytelniania

❌ VPN

❌ Zero Trust

GeoIP jest warstwą dodatkową.

Kiedy GeoIP Blocking ma sens?

Szczególnie gdy:

1. Usługa ma ograniczony zasięg geograficzny

Polska → biznes
Reszta świata → brak potrzeby dostępu

2. Chcesz ograniczyć powierzchnię ataku

Zmniejszenie liczby potencjalnych źródeł ruchu może ograniczyć część automatycznego skanowania.

3. Chronisz panel administracyjny

Jako dodatkowa warstwa.

4. Masz określone wymagania biznesowe

Np. aplikacja przeznaczona tylko dla użytkowników określonych regionów.

Kiedy GeoIP jest złym pomysłem?

Jeżeli aplikacja jest globalna:

Global Users
     |
     v
Application

blokowanie całych państw może powodować problemy z legalnymi użytkownikami.

Także w przypadku:

• usług SaaS,
• globalnych API,
• VPN,
• usług chmurowych,
• międzynarodowych firm.

GeoIP Blocking w architekturze bezpieczeństwa

Najlepiej traktować go jako jeden z sygnałów:

                    REQUEST
                       |
          +------------+------------+
          |            |            |
        GeoIP      Reputation     Rate Limit
          |            |            |
          +------------+------------+
                       |
                      WAF
                       |
                     IDS/IPS
                       |
                       v
                   Application

Przykładowa polityka

Dla małej firmy:

Internet
   |
   v
Firewall
   |
   +-- GeoIP
   |
   +-- Reputation
   |
   +-- Rate Limit
   |
   v
Reverse Proxy
   |
   v
WAF
   |
   v
Application

Dla panelu administracyjnego:

Internet
   |
   v
VPN / Zero Trust
   |
   v
MFA
   |
   v
Admin Panel

To drugie rozwiązanie jest zdecydowanie mocniejsze niż samo GeoIP.

Podsumowanie

GeoIP Blocking może skutecznie ograniczyć część niepożądanego ruchu, ale nie powinien być traktowany jako samodzielny mechanizm bezpieczeństwa.

Najważniejsze zasady:

• GeoIP ≠ dokładna lokalizacja użytkownika
• VPN i proxy mogą ominąć geoblokadę.
• Baza GeoIP musi być aktualizowana.
• Należy uwzględnić IPv4 i IPv6.
• Nie należy bezrefleksyjnie blokować całych państw.
• GeoIP najlepiej łączyć z WAF, IDS/IPS, rate limitingiem i MFA.
• Dla administracji lepszy jest VPN/Zero Trust niż samo GeoIP.

Najlepszy model:

                 INTERNET
                    |
                 Firewall
                    |
              +-----+------+
              |            |
            GeoIP      Reputation
              |            |
              +-----+------+
                    |
                   WAF
                    |
                 IDS/IPS
                    |
                   MFA
                    |
                Application

GeoIP powinno być filtrem pomocniczym, a nie granicą bezpieczeństwa. W nowoczesnej architekturze bezpieczeństwa warto traktować kraj pochodzenia adresu IP jako jeden z wielu sygnałów ryzyka, a nie jako dowód, że użytkownik jest zaufany lub niezaufany.

Polecane wpisy

Konfiguracja MikroTik – Część 36: Automatyzacja zarządzania adresacją IP i DHCP z wykorzystaniem skryptów

Konfiguracja MikroTik – Część 36: Automatyzacja zarządzania adresacją IP i DHCP z wykorzystaniem skryptów Współczesne sieci wymagają nie tylko stabilności Czytaj dalej

Jak działają ukryte mosty (bridges) w Tor i omijanie cenzury internetu

Jak działają ukryte mosty (bridges) w Tor i omijanie cenzury internetu Ukryte mosty (bridges) to jeden z kluczowych mechanizmów pozwalających Czytaj dalej