Vserver præsentation

Indledning

• hvem er jeg?

• Hvordan med spørgsmål?

• Denne præsentation kan hentes på nettet (www.vsen.dk – under vserver)

• HUSK - telefoner på Lydløs/meeting profil - tak :-)

Vserver konceptet

• Kort introduktion (hjemmesiden www.linux-vserver.org)

• Distributioner

• hvorfor vælge vserver?

  • GPL

  • Stabilitet

  • Bedre ressourceudnyttelse

  • Øget/nemmere Sikkerhed

  • Failover

  • Intrusion Detection

  • Central Process Monitoring og Backup.

  • Bedre displads udnyttelse.

  • Nem deling af biblioteker imellem vservere.

• Hvordan fungerer vserver?

  • Filsystemet

  • Processer

  • Netværk

  • Root-capabilities

  • System V IPC

  • Ressourcefordeling

• Alternativer

  • User-Mode Linux/VMware

  • FreeVSD

• Opsætningseksempel

• Live præsentation

Indledning:

Hvem er jeg?

Klavs Klavsen, I kender mig måske fra sslug listerne – hvor jeg forsøger at hjælpe folk når jeg har tiden og lige kender svaret :-)

Uden at give mit CV, har jeg været ansvarlig for al IT drift (inkl. Sikkerhed) og HW indkøb hos Metropol Online (tidl. Berlingske Online – ansvarlig for drift af ca. 20 sites, inkl. bt.dk, berlingske.dk osv.) i 3 år, og er i 2002 blevet selvstændig.

hvordan med spørgsmål?

Ræk hånden op når i har nogle, så skal jeg forsøge at besvare dem, ellers vil jeg henvise til at de bliver besvaret senere i præsentationen.

Denne præsentation kan hentes på nettet.

I kan hente den på www.vsen.dk – under vserver menu punktet – der er udover disse slides, også en opsummering af det jeg siger i dag.

Vserver Konceptet:

Kort introduktion.

Historien – Første release – v0.0 (blev v.0.1 samme dag) kom d. 2 Okt. 2001. Der var vserver allerede 100% funktionel og i brug af udgiveren Jacques Gelinas.

Vserver består af nogle utilities og et kerne-patch.

Kerne patchet tilføjer:

• en ekstra attribut (ses med mod. Lsattr) kaldet immutable-unlink/immutable-linkage-invert til ext2/ext3 (og reiserfs har vist også fået de attribut muligheder nu). Fortæller om brugen senere.

• et koncept kaldet Security Context's til kernen, hvor hver vserver har sit eget Security Context ID, og det er dette ID der bruges til at skille de forskellige vservers processor fra hinanden.

• Et par nye systemkald (new_s_context, set_ipv4root) som udnyttes af de tilhørende utilities.

• En række ændringer til at skille f.ex. IPC osv. Imellem vserverne – vha. Security Context ID'et.

• Et “fix” af de 2 kendte chroot sårbarheder, således at det chroot kald brugt af vserverene ikke kan undslippes (så vidt vides). Dette hjælper dog ikke den normale chroot – som stadig fungerer som vanligt i hver enkelt vserver (og derfor ikke får et nyt Security Context ID – hvilket er forskellen).

Vis “billede af vservere”.

Ide'en er at køre flere “virtuelle” servere på en server, hvor root i en virtuel server er frataget alle, eller næsten alle (eget valg) capabilities og dermed ikke er root som vi kender den.

Oftest kører man en vserver pr. Service.

Hver vserver startes, ved at starte en init under chroot i dens eget “filsystem” som normalt ligger under /vserver/vserver-navn. Denne init, gør så det som den plejer når din linux-boks starter op – for den enkelte vserver.

Distributioner:

Vserver virker med alle distro'er, dog med lidt umiddelbare mangler for ikke RPM/Deb baserede systemer, da nogle utilities er baseret på disse – se hvordan – filsystemet.

Debian support er godt på vej (detaljer vides ikke – spørg på mailinglisten så skal du nok få dit svar) – se alle detaljer på vserver's hjemmeside:

http://www.linux-vserver.org

Hvorfor vælge vserver?

Fordele ved at bruge vserver:

• GPL

  Vserver er frigivet under GPL licensen – så brug den trygt.

• Stabilitet

  • Laver kun en del mindre ændringer (ingen ram segregering)

  • i drift hos bl.a. flere hosting firmaer i USA (iflg. Mailinglisten).

  • gode erfaringer med vserver under pressede situationer (iflg. Mailinglisten).

• Bedre ressourceudnyttelse

  • ikke længere installere services på seperate servere, af sikkerhedsmæssige årsager - kun af server-ressourcemæssige årsager.

  • Dine services eksekveres lige så hurtigt som havde du ikke brugt vserver

  • Nemt at flytte services og brugere, ved at flytte hele vserver mappen.

    .

• Sikkerhed

  • Normalt er hacket service = Opnåelse af Ægte Root (dvs. Med alle capabilities som normalt), selvom denne er chrooted.

  • Ægte Root findes ikke i en vserver – og dermed kan han ikke override sikkerhedsforanstaltninger såsom, Append-only logfiler, Iptables, Promiscious mode, ændring af netværkssettings osv.

  • Chroot af services kan normalt være besværligt, og kan omgås hvis hackeren kan opnå root-adgang.

• Failover

  • Fail over servers er normalt besværligt – Nu er det nemt, da man bare skal have en tar-ball af sin vserver liggende og systemet kører straks uden ændringer.

  • At starte vservere over f.ex. NFS funker 100% og så længe man ikke kører Disk intensive programmer på NFS partitionen, så er der ingen problemer.

  • Sammen med vservere på NFS, vil man umiddelbart nemt kunne sætte f.ex. Sit NMS til at starte en service op på en ny maskine, hvis servicen ikke svarer længere.

• Intrusion Detection

  • Root-kits og smarte hackere, kan normalt narre/ødelægge fil-baserede IDS systemer og/eller gøre det svært for system administratoren at se om maskinen er blevet kompromiteret.

  • Med vserver kan Real Root – serveren som ingen services kører, håndtere dette – og f.ex. Sætte en logfil under en vserver i append-only mode (ext2/3) og root i vserveren kan intet gøre ved dette pga. Manglende capabilities.

  • rpm's -V funktion kan benyttes, da rpm-databasen kan beskyttes – så hackere ikke kan ændre den, eller rpm-bin'en. Så skal man ikke vedligeholde eget fil-IDS.

  • Man kan beskytte (vha. Immutable bitten) de filer/programmer man ikke ønsker at en vserver-bruger kan opdatere/eller at en hacker må pille ved. Så vil et root-kit ikke have nogen effekt.

• central process monitorering og backup.

  • Pr. fysisk pc, kan overvågning køre på root-serveren og den kan dermed ikke forhindres/obstrueres af nogle brugere på den enkelte vserver.

  • root-serveren kan tilgå filerne i vserverne direkte og kan dermed sikre backup af dem alle.

• Bedre Diskplads udnyttelse

  • vha. Immutable Hardlinks kan flere vservere dele standard filerne og en 2gb installation, fylder kun omkring 40mb pr. Vserver – resten er delte filer.

  • Denne deling af immutable filer, fjernes hvis filen sættes med den ny bit Immutable-unlink – så vil den vserver der prøver at ændre i en delt fil, få en lokal kopi af denne – ligesom med Copy-On-Write i Shared Memory. Er kun immutable sat, vil vserveren ikke få lov.

• Deling af biblioteker imellem servere.

  Vha. Mount --bind kan man dele biblioteker imellem flere vservere. Desværre understøtter kernen ikke at man ændrer mount options, som f.ex. -o ro. Kommer/er(?) måske i 2.5.

Hvordan fungerer vserver?

Hver vserver er adskilt i forhold til følgende:

• Filsystemet

  • Hver enkelt vserver har alle sine filer liggende under /vserver/<vservernavn>/ og ingen process på den enkelte vserver kan komme udenfor dette bibliotek – dette gøres vha. Standard Chroot – og det nye new_s_context kald.

  • Det er muligt at dele biblioteker, vha. Mount -bind (problem med ændring af mount-options – Ikke muligt – måske i 2.5).

  • Immutable-unlink til ext2/3 bruges, så man ikke skal have et komplet standard install dubleret over flere vservere og den enkelte vserver stadig kan opgraderes seperat hvis det ønskes.

• Processer

  • Hver enkelt process, får tilføjet et context ID som fortæller hvilken vserver de hører til.

  • Root serveren har Context ID 0 og er den eneste der kan skifte imellem Security Context's.

  • Hver enkelt vserver, inkl. Root serveren, kan KUN se processer der kører i dens egen context.

  • Man kan se alle processer, vha. Context ID 1, og da kun Security Context 0, kan skifte til Security Context 1, kan kun real root bruge denne mulighed.

  • Der er utilities til at gøre dette nemmere som f.ex. Vps

• Netværk

  • Hver vserver får sit eget hostnavn og egen/egne UNIK(ke) IP(er) (vha. Ip-alias på et eller flere givne interfaces).

  • Skal alle services tilgås fra samme IP, bruges Iptables DNAT til at omskrive de indkomne pakker.

• Root-capabilities

  • Alle de egenskaber (capabilities under Linux) er hvad der gør Root så powerful. Disse er fjernet i hver vserver og root i vserveren kan derfor bl.a. Ikke sætte netkortet i promiscious mode, mounte noget som helst etc. Der kan tilføres bestemte capabilities til en bestemt vserver om man har brug for dette –

  • bl.a. Kræver Bind indtil videre at man giver den cap_sys_ressources (control over ulimits).

  • For at undgå at en root-process i en vserver kan tilegne sig nye capabilities (som de normalt vil kunne) er der tilføjet en cap_bset variabel i kernen, som sætter loftet for hvilke capabilities den enkelte process kan tilegne sig.

• System V IPC

System V IPC ressourcerne er seperate pr. Vserver - da processens context ID tilføjes til tildelingen og tilgangen af disse.

• Ressourcefordeling

Ulimits bruges til at begrænse de enkelte vservers begrænsninger

Dette virker indtil videre ikke for alle limits, indtil videre kun for:

• antal samtidige processer,

• antal cpu-clocks brugt (lavet i scheduleringen, så en vserver får process-tid i forhold til dens nice-værdi - uanset antallet af processer. 1 vserver med 50 processer og en med 1 process, vil få lige mange cpu-clocks - medmindre den ene har en anden nice-værdi). Ikke optimalt, men betyder dog at en vserver ikke kan DOS'e på denne måde.

Der mangler:

• Diskplads begrænsning/quotas (kan løses vha. f.ex. lvm partitioner med en vserver på hver sin lvm (eller et antal lvm) – minus er ingen unifying af filer,

• begrænsning af antal åbne filer pr. vserver,

• begrænsning af ram mængden brugt.

Så det er faktisk muligt at DOS'e de andre vservere.

Alternativer

• VMware/User-Mode Linux

  + De baserer sig begge på 100% adskillelse, og hver enkelte virtuelle server har sin egen del af den tilgængelige hardware (ram, disk osv).

  + VMware kræver ikke at man ændrer på sin kerne.

- De enkelte virtuelle servere på samme maskine, kan ikke “låne” kapacitet fra de andre, hvis de ikke laver noget og den har travlt.

- Giver ikke 100% performance.

- VMware koster kr.

- User-Mode Linux laver alvorlige(ram-segration osv.) ændringer på kernen (141kb patch)

- Giver ikke 100% performance.

• FreeVSD

Er opbygget på samme grundlag som vserver, med ressourcefordeling osv., men er efter alt hvad jeg har hørt MEGET besværlig at sætte op og på ingen måde bedre. Ydermere er projektet vist også ved at dø (sidste ændring 2. juli 2001).

Opsætningseksempel:

1. Hent vserver og vserver-admin rpm'erne og patch-2.4.19ctx-13 fra http://www.linux-vserver.org

2. rpm -Ivh vserver*.rpm

3. udpak en 2.4.19 vanilla kerne i /usr/src/linux

4. cd /usr/src/linux

5. cat patch-2.4.19ctx-13 | patch -p1

6. sæt kernen op som den skal være det for at køre på din pc, kompiler og installer den som vanligt.

7. Genstart på ny kerne.

8. Kør newvserver – installer evt. Ved at tage kopi af root-serveren (alle rpm pakkerne bliver “gen-installeret” under /vserver/vserver-navnet/* eller lav en nyinstallation fra redhat's cd'ere (også vha. Newvserver).

9. Skriv: vserver vserver-navn enter

10. Installer/af-installer de rpm'er du vil have i din vserver (fjern start af netværk og andre services som root-serveren tager sig af, og din vserver kan nu startes og stoppes fra root-serveren.

11. Sæt port omskrivning til din nye service i vserveren hvis nødvendigt, sådan her:

iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.2 --destination-port 563 -j DNAT --to-destination 192.168.1.100

Live Præsentation:

• åben 2x xterm på tværs

• vserver test enter i den ene og start postfix (bemærk at config er magen til root's)

• hvis netstat -na og pstree / ps faux

• lav pstree i root – ingen postfix (stop lige egen postfix først :-)

• lav vps fax

• lav netstat -nta | grep LISTEN