IPSEC sutter

Jeg har en forholdsvis simpel netværksopgave jeg skal have løst: tre sites og en laptop over det hele skal kunne tale sammen.

Den officielle protocol til den slags hedder IPSEC og den er lavet af nogle af de skarpeste kryptografer i skuffen, folk af den kaliber hvor man skal kunne faktorere store primtal i hovedet før de overhovedet vil give en et håndtryk.

Protokollen er også blevet målt, vejet og godkendt af NSA, CERT, NIST, FDB, ministeriet for Windows og Word og samvirkende danske husmoderforeninger.

Firmaer som Cisco tjener formuer på at sælge udstyr og software der tillader folk at oprette "Virtuelle Private Netværk" med IPSEC protokollen.

Men jeg vil stædigt fastholde at den sutter.

IPSEC er for sikkerhed hvad traktater er for mellemfolkelig statsret: alt for mange ord, alt for lidt handling og alt for besværlig og sendrægtig at få til at virke.

Hvis jeg vil have en sikker tunnel imellem to maskiner, så burde det ikke tage mere end tre kommandoer i begge ender af forbindelsen:

  • Generer en lokal nøgle
  • Send den til den anden side (f.eks med scp(1))
  • Konfigurer tunnellen med de to nøgler.

Hvorfor kan man ikke det med IPSEC ? Alle de HOWTO, tutorials og andet jeg kan finde indeholde masser af lange configfiler, fyldt med felter hvor kommentaren siger "ret for guds skyld ikke de her" eller "jeg ved ikke hvad de her gør, men det virker for mig".

Er der andre end mig der er trætte af den slags ?

Istedet bruger jeg ssh(1)'s nye -w option. Jeg er ikke kommet helt ned på 2x3 kommandoer per tunnel, men det er tæt på: ssh-keygen for at lave en identitet, vælg ipnumre og /dev/tun nummer, lav en linie i authorized_keys der starter med

tunnel="12",command="ifconfig tun12 10.0.0.12 10.0.0.13" ...

og i den anden ende starter jeg under boot et lille shellscript:

while true
do
ifconfig tun12 10.0.0.13 10.0.0.12
ssh -n root@remotehost -w12:12 -i /etc/tunnel_12_key date
sleep 10
done

Hatten af for OpenSSH, det er krypto der faktisk kan bruges!

phk

PS: behøver jeg overhovedet påpege at jeg slipper for at have ipsec-tools og IPSEC konfigureret og derfor heller ikke behøver at tænke på de advisories der måtte komme imod dem ?

Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Flemming Jacobsen

Med ssh baseret VPN får du en del uhensigtsmæssigheder (google: tcp over tcp), specielt lange perioder uden flow i din session, hvis din tunnel forbindelse oplever pakketab.

Det fungerer nu generelt godt i praksis - men jeg oplever indimellem at mit eget ssh baserede VPN har perioder med no-flow i 15+sek ad gangen.

  • 0
  • 0
Kristian Thy

Det er fredag eftermiddag; jeg har brug for at andre tænker for mig: Indebærer

Generer en lokal nøgle
Send den til den anden side (f.eks med scp(1))

ikke at du allerede har sendt en nøgle til den anden side, så du kan logge ind med scp? Hvordan fik du den over på den anden side? Måske med

Generer en lokal nøgle
Send den til den anden side (f.eks med scp(1))

men det er jo hønen og ægget! Det er mere end jeg kan kapere når det er weekend om 3 timer. Pap, saks, tak.

  • 0
  • 0
Benjamin Krogh

"man skal kunne faktorere store primtal i hovedet før de"

Lige netop det vil jeg påstå at de fleste mennesker er i stand til. Endda uden besvær. Især fordi et primtal p kun kan faktoriseres i: 1 * p, da det jo ellers ikke ville være et primtal.

  • 0
  • 0
Lasse Bach

Hej Poul Henning.

Uden selv at have prøvet at sætte ipsec, har jeg da læst lidt artikler om at OpenBSD's ipsec opsætning skulle være ret ligetil.

Her er et par links:
http://www.serverwatch.com/tutorials/article.php/3659686
http://www.securityfocus.com/infocus/1859
http://openbsd.org/papers/asiabsdcon07-ipsec/index.html

Nu ved jeg godt at du nok kun er interesseret i FreeBSD, men hvis det er så simpelt som første link hentyder til, så kunne det måske være lidt inspiration til hvordan det også kan gøres i FreeBSD.

  • 0
  • 0
Jens Fallesen

Det behøver nu ikke at være kompliceret at få IPSEC til at køre. Mange kommercielle leverandører har løsninger, der er meget nemme at have med at gøre – vel og mærke uden at være mindre sikre.

Men det er da rigtigt, at IPSEC indeholder (mulighed for) så meget kompleksitet, at det kan blive langhåret, hvilket desværre også har medført, at mange af disse nemme løsninger ikke er indbyrdes kompatible.

Man skulle egentlig mene, at der burde være basis for at lave tilsvarende løsninger baseret på open source, men jeg må indrømme, at jeg ikke ved, hvor svært det ville være at portere IPSEC-software mellem Linux og BSD-varianterne.

  • 0
  • 0
Henrik Kramshøj Blogger

phk:Der er ingen af de links der peger på noget jeg vil kalde "simpelt".

Huh?
Artiklen "Zero to IPSec in 4 minutes" på adressen:
http://www.securityfocus.com/infocus/1859
er da så simpelt som det kan blive?!

Den beskriver hvordan du sætter IPsec op på under 5 minuttter, inklusiv firewallændringerne som tillader trafikken.

Samme slags artikler finder du hos alle andre leverandører. Det sværeste ved IPsec er at de forskellige produkter bruger forskellige navne på algoritmerne. Eksempelvis kalder et produkt det for aes128-cbc mens en anden måske kalder det rijndael.

IPsec er sgu ikke så svært som du gør det til, men hvis man ikke selv skal konfigurere begge ender bliver det svært!

  • 0
  • 0
Anders Porsbo

Jeg lavede en opgave om VPN i et kryptografi fag paa uni.

Det viste sig at de mange mange forskellige implementationer af IPSec knap er kompatible. Det skal da heller ikke vaere nogen hemmelighed at
RFC 4302,4305 om Authentication Header og RFC 4303,4305 om Encapsulation Security Payload (hovedingredienser i IPSec) er ret omfattende.

Der er indtil flere steder hvor man kan misforstaa RFC'en, eller som programmoer maa beslutte sig for hvordan det mon var ment.

Hvorom alt er, fandt jeg frem til at IPSec skulle jeg kun regne med at faa op at koere hvis jeg brugte samme implementation i begge ender af VPN'et.

Derfor besluttede jeg at bruge OpenVPN som koerte paa de systemer jeg skulle bruge (incl OpenWRT).

OpenVPN kan paa grund af sin portabilitet ogsaa godt forsvares at blive brugt i stedet for WPA2 i wifi, synes jeg.

Hvis nu ikke mit perl script (til at administrere OpenVPN noegler og generere filer til nye brugere) var saadan noget humbuk, ville jeg med glaede have delt det... overvejer om det skal finpudses lidt, og deles med offentligheden :)

  • 0
  • 0
Dennis Krøger

Jeg lavede en tilsvarende opgave på min ingeniørhøjskole, og der kørte vi en Linux (med Racoon), en ZyWall og en Windows sammen med IPSEC i forkellige konfigurationer, AH/ESP, transport/tunnel, password/signatur, transport IGENNEM tunnel (det sidste lykkedes aldrig, men det er vist mest en konfiguations begrænsning i Racoon)...

Det meste var ikke så slemt, bortset fra at det var et helvede at sætte Windows op, men det var uanset om det var imod en anden Windows eller et af de andre systemer.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize