Problem występujący w mojej domowej sieci WLAN można streścić następująco: mój AP nie robi nic poza WEP, który okazuje się trywialny do złamania. Konieczna jest więc dodatkowa ochrona poufności ruchu w WLAN.

Pierwsze rozwiązanie, które mi się narzucało to wykorzystanie natywnego IPSec z Windows i isakmpd z OpenBSD. Rozwiązanie to działa, ale z jednym wyjątkiem: Windows ma problemy z trybem tunelowym. Jestem w stanie automatycznie szyfrować cały ruch LAN-LAN, ale ruch w relacji LAN-świat idący na odcinku stacja-router jest nieszyfrowany.

Jest to dla mnie częściowo do zaakceptowania, bo głównym zmartwieniem jest nieszyfrowana transmisja między stacjami w LAN. Ten cel udało się zrealizować. Ruch ze stacji na świat i tak zwykle idzie innymi szyfrowanymi protokołami (SSL, SSH).

OpenBSD

W sieci wdrożyłem najprostszą możliwą architekturę IPSec opartą o pre-shared key identyczny na wszystkich stacjach. Jest to prostackie sprowadzenie IPSec do czegoś w rodzaju WPA-PSK, ale mi to wystarcza.

Konfiguracja po stronie OpenBSD, plik /etc/isakmpd/isakmpd.conf:

[Phase 1]
Default=                any

[any]
Phase=                  1
Configuration=          Default-main-mode
Authentication=         HASLO-HASLO-HASLO

[Default-main-mode]
EXCHANGE_TYPE=          ID_PROT
Transforms=             AES-SHA,3DES-SHA

Wymowa tego fragmentu jest lakoniczna: puszczaj każdego, kto się poprawnie uwierzytelni podanym hasłem po IKE. Dodatkowo w OpenBSD trzeba podać politykę w /etc/isakmpd/isakmpd.policy:

Authorizer: "POLICY"
Licensees: "passphrase:HASLO-HASLO-HASLO"
Conditions: app_domain == "IPsec policy" &&
            esp_present == "yes" &&
            esp_enc_alg != "null" -> "true";

Zacząłem to też testować na certyfikatach X.509 i zasadniczo działa, ale potem zrezygnowałem jak zaczęły się problemy z trybem tunelowym po stronie Windows i tak zostało. Oczywiście, Windows XP nie obsługuje AES w IPSec :-\

Windows

Po stronie Windows dodaję politykę IPSec przy pomocy konsoli:

1. Uruchamiam mmc
2. Dodaję snapshot IP Security Policies on Local Computer
3. Prawym Create IP Security Policy
4. Wszystko na domyślnych do okna Default Response Rule Authentication Method, wybieram Use this string... i podaję "HASLO-HASLO-HASLO"
5. Finish z włączonym Edit properties przenosi do okienka z konfiguracją filtrów. I tutaj jest kluczowe.
6. Do istniejącego Dynamic Default Response dodaję (Add) kolejny filtr.
7. W Tunnel endpoint zostawiam "This rule does not..."
8. W Network Type wybieram LAN
9. W Authenticaton method podaję hasło jak wyżej.
10. W oknie IP Filter List wybieram Add, pojawia się okno definicji filtra
    1. Znowu Add i wizard
    2. W IP Traffic Source wybieram "My IP Address"
    3. W IP Traffic Destination wybieram "A specific IP Subnet" i wpisuję swoją sieć lokalną
    4. Do końca na domyślnych, OK.
11. W okienku IP Filter List należy zaznaczyć kropką nowo utworzony filtr i Next.
12. W Filter Action wybieram Require Security żeby do stacji nie można było się dobić bez IPSec - czyli bez uwierzytelnienia.
13. Next, Finish, OK, Close.
14. W głównym oknie konsoli mmc pojawia się nowa polityka IPSec. Teraz żeby ją uruchomić należy kliknąć prawym i dać Assign.

Teraz przy pierwszym ruchu sieciowym do stacji w LAN Windows powinien próbować najpierw nawiązać ISAKMP, a potem cały ruch powinien iść po IPSec. Bez IPSec nie powinno być możliwe skontaktowanie się z daną stacją, na której skonfigurowaliśmy politykę IPSec jak wyżej.

Wygląda to jak poniżej. Akurat to początkowe ISAKMP zostało sprowokowane przez zapytanie do DNS skierowane do OpenBSD (który jest nameserverem).

20:35:04.446567 toshiba.local.isakmp > gw.local.isakmp:  isakmp v1.0 exchange QUICK_MODE encrypted
        cookie: 6673a330f301dcfe->e6d4075ece8ce9f0 msgid: 22c2bbb3 len: 204
20:35:04.453368 gw.local.isakmp > toshiba.local.isakmp:  isakmp v1.0 exchange QUICK_MODE encrypted
        cookie: 6673a330f301dcfe->e6d4075ece8ce9f0 msgid: 22c2bbb3 len: 164
20:35:04.454742 esp toshiba.local > gw.local spi 0x239290E7 seq 1 len 68
20:35:04.455283 toshiba.local.isakmp > gw.local.isakmp:  isakmp v1.0 exchange QUICK_MODE encrypted
        cookie: 6673a330f301dcfe->e6d4075ece8ce9f0 msgid: 22c2bbb3 len: 52
20:35:05.435456 esp toshiba.local > gw.local spi 0x239290E7 seq 2 len 68
20:35:05.437144 esp gw.local > toshiba.local spi 0x50F26C95 seq 1 len 108
20:35:05.438136 esp toshiba.local > gw.local spi 0x239290E7 seq 3 len 68
20:35:05.439576 esp gw.local > toshiba.local spi 0x50F26C95 seq 2 len 108

Dodajmy, że OpenBSD nie jest tutaj do niczego potrzebne, bo stacje w LAN dogadują się po ISAKMP między sobą. OpenBSD uczestniczy w tej komunikacji jak równy z równym, dzięki czemu przynajmniej ruch do bramki jest szyfrowany.

20:38:05.158215 esp toshiba.local > asus.local spi 0xE4D68A11 seq 1 len 76
20:38:05.159408 esp asus.local > toshiba.local spi 0xABCBD7DC seq 1 len 76
20:38:17.032640 esp optimus.local > toshiba.local spi 0xD4D64BF3 seq 40 len 52 (DF)
20:38:17.035345 esp toshiba.local > optimus.local spi 0x1ADB8AA6 seq 47 len 52 (DF)
20:38:23.120899 toshiba.local > ns1.siteground14.com: icmp: echo request
20:38:23.287413 ns1.siteground14.com > toshiba.local: icmp: echo reply
20:38:35.763226 esp toshiba.local > optimus.local spi 0x1ADB8AA6 seq 48 len 76
20:38:35.764480 esp optimus.local > toshiba.local spi 0xD4D64BF3 seq 41 len 76

Wydajność

Test wykonany w różnych kombinacjach przy pomocy ttcp po TCP. Bloki 16-32 MB.

Wygląda na to, że AMD-K6 300 MHz jest wąskim gardłem. Karta SIS obsługuje tylko WLAN 11mbit/sek.

Wnioski

Postawienie natywnego windzianego IPSec między stacjami rozwiązuje problem bezpieczeństwa stacji w LAN bo:

• do stacji nie można połączyć się bez IPSec
• ruch między stacjami jest szyfrowany (głównie transfery plików)

Software'owy WEP w OpenBSD nie stanowi żadnego problemu. Do dopracowania jest jeszcze ruch gw-stacje.