GRE + IPSec czyli bezpieczeństwo i higiena pracy w tunelach

Posted on pią 12 listopad 2010 in misc

W jednym z poprzednich wpisów pokazałem jak na routerach kilku różnych producentów zestawić tunel GRE. Przypomnijmy – GRE jest popularnym sposobem na łączenie zdalnych sieci – taki tunel działa jak bezpośredni link pomiędzy nimi. Pakiety IP lub IPv6 są encapsulowane w pakiecie GRE i przesyłane np. przez Internet. Podstawową wadą takiego rozwiązania jest brak wbudowanych mechanizmów bezpieczeństwa, dlatego też GRE prawie nigdy nie jest stosowany bez dodatkowych zabezpieczeń oferowanych przez inne mechanizmy (a przynajmniej każdy administrator, który choć odrobinę dba o bezpieczeństwo własnej sieci na to nie pozwoli). Najpopularniejszym sposobem na zapewnienie poufności danych przesyłanych tunelem GRE jest zastosowanie IPSec.

Nad samym IPSec nie będziemy się tu specjalnie rozwodzić – napisano już na ten temat dość i jeśli ktoś potrzebuje czegoś więcej niż HOWTO bez problemu znajdzie odpowiednią literaturę. Dość wiedzieć, że IPSec zapewnia:

  • autentykację
  • spójność danych – mamy pewność, że nikt ich nie zmodyfikował
  • poufność – szyfrowanie za pomocą algorytmu AES (Advanced Encryption Standard) lub 3DES

Pamiętacie przykład z tunelem GRE? Nieco go zmodyfikujemy i tym razem skupimy się na Vyatta.

GRE +
IPSec

Konfiguracja tunelu GRE

Tunel GRE skonfigurujemy pomiędzy interfejsami loopback obu routerów. Interfejs loopback to bardzo przydatne narzędzie w wielu sytuacjach. Tu posłuży nam za końcówkę naszego tunelu. Oczywiście aby wszystko działało tak jak powinno, podobnie jak interfejs publiczny (WAN czy jak go tam nazwiemy) także musi być osiągalny z Internetu.

[edit]
vyatta@R1# set interfaces loopback lo address 172.16.0.1/32
[edit]
vyatta@R1# set interfaces tunnel tun0 encapsulation gre
[edit]
vyatta@R1# set interfaces tunnel tun0 local-ip 172.16.0.1
[edit]
vyatta@R1# set interfaces tunnel tun0 remote-ip 172.16.0.2
[edit]
vyatta@R1# set interfaces tunnel tun0 address 10.255.255.1/30

Na koniec oczywiście odpowiednia trasa do zdalnej podsieci.

[edit]
vyatta@R1# set protocols static route 192.168.2.0/24 next-hop 10.255.255.2

Na drugim routerze konfiguracja przebiega analogicznie.

IPSec

No ok. Pora na zabezpieczenie naszego tunelu. Zastanówmy się co chcemy zrobić. Każdy pakiet GRE opuszcza nasz router z adresem źródłowym interfejsu loopback lokalnego routera i adresem docelowym interfejsu loopback routera zdalnego. Właśnie każdy taki pakiet chcemy szyfrować.

Samo połączenie IPSec (negocjacja kluczy itd.) korzysta z adresów skonfigurowanych na interfejsach eth0 obu routerów.

No dobra zacznijmy od zdefiniowania w jaki sposób router ma szyfrować dane:

[edit]
vyatta@R1# set vpn ipsec ike-group IKE-TO-R2 lifetime 3200
[edit]
vyatta@R1# set vpn ipsec ike-group IKE-TO-R2 proposal 1 encryption aes256
[edit]
vyatta@R1# set vpn ipsec esp-group ESP-TO-R2 lifetime 1600
[edit]
vyatta@R1# set vpn ipsec esp-group ESP-TO-R2 proposal 1 encryption aes256
[edit]
vyatta@R1# set vpn ipsec ipsec-interfaces interface eth0

OK. Pokrótce co zrobiliśmy:

ike-group – tworzymy deklaracje metod kryptograficznych używanych podczas negocjowania kluczy.
esp-group – tworzymy deklaracje metod kryptograficznych używanych podczas szyfrowania danych.

Na każdym z routerów możemy zdefiniować kilka deklaracji (proposal) podczas negocjacji będzie wybrana najsilniejsza opcja dostępna na obu urządzeniach.

OK. Kolejnym krokiem będzie zdefiniowanie peera czyli routera, z którym mamy gadać.

vyatta@R1# edit vpn ipsec site-to-site peer 2.2.2.2
[edit vpn ipsec site-to-site peer 2.2.2.2]
vyatta@R1# set authentication mode pre-shared-secret
[edit vpn ipsec site-to-site peer 2.2.2.2]
vyatta@R1# set authentication pre-shared-secret tajnehaslo
[edit vpn ipsec site-to-site peer 2.2.2.2]
vyatta@R1# set ike-group IKE-TO-R2
[edit vpn ipsec site-to-site peer 2.2.2.2]
vyatta@R1# set local-ip 1.1.1.1
[edit vpn ipsec site-to-site peer 2.2.2.2]
vyatta@R1# set tunnel 1 esp-group ESP-TO-R2
[edit vpn ipsec site-to-site peer 2.2.2.2]
vyatta@R1# set tunnel 1 local-subnet 172.16.0.1/32
[edit vpn ipsec site-to-site peer 2.2.2.2]
vyatta@R1# set tunnel 1 remote-subnet 172.16.0.2/32

Voila! Do autentykacji oba peery będą używać współdzielonego hasła (można użyć jeszcze klucza rsa co jest bezpieczniejsze ale nieco bardziej pracochłonne w konfiguracji ;)). Wybieramy wcześniej ustaloną grupę IKE. Następnie definiujemy tunel. Zwróćcie uwagę, że local-subnet i remote-subnet ustawione są na adresy naszych loopbacków. Jak najbardziej da to wymagany efekt – każdy pakiet GRE będzie wychodził właśnie z takimi adresami źródłowymi i docelowymi – w efekcie zostanie zaszyfrowany.

Konfiguracja IPSeca powinna wyglądać mniej więcej tak:

vpn {
    ipsec {
        esp-group ESP-TO-R2 {
            lifetime 1600
            proposal 1 {
                encryption aes256
            }
        }
        ike-group IKE-TO-R2 {
            lifetime 3200
            proposal 1 {
                encryption aes256
            }
        }
        ipsec-interfaces {
            interface eth0
        }
        site-to-site {
            peer 2.2.2.2 {
                authentication {
                    mode pre-shared-secret
                    pre-shared-secret tajnehaslo
                }
                ike-group IKE-TO-R2
                local-ip 1.1.1.1
                tunel 1 {
                    esp-group ESP-TO-R2
                    local-subnet 172.16.0.1/32
                    remote-subnet 172.16.0.2/32
                }
            }
        }
    }
}

Tym sposobem dowiedzieliśmy się jak bezpiecznie poruszać się w tunelach.

Następnym razem powrót do IPv6, czyli kolejna pełna potu, łez i krwi historia o rodzącym się w bólach Internecie v2.

FIN