mboost-dp1
VMware
Den sevanelig snak om sikkerhedshuller og om software så skal bruges.
Så længe sikkerhedshullerne bliver rettet når de bliver opdaget/indberettet så kan jeg ikke så det store problem i det her.
Windows har også sikkerhedshuller (mange) men det gør ikke at jeg lader være at bruge windows.
Det er lidt ligesom snakken om firefox | internet explorer, begge har haft sikkerhedshuller men så længe de bliver rettet indenfor rimelig tid er det vel ikke det store problem.
Populært software vil altid blive benyttet af mange kunder og af hackere/crackere og andre med mindre "gode" intentioner.
Så længe sikkerhedshullerne bliver rettet når de bliver opdaget/indberettet så kan jeg ikke så det store problem i det her.
Windows har også sikkerhedshuller (mange) men det gør ikke at jeg lader være at bruge windows.
Det er lidt ligesom snakken om firefox | internet explorer, begge har haft sikkerhedshuller men så længe de bliver rettet indenfor rimelig tid er det vel ikke det store problem.
Populært software vil altid blive benyttet af mange kunder og af hackere/crackere og andre med mindre "gode" intentioner.
Det kan godt være VMware har nogle huller, men det er stadigvæk skidesmart :) hvis man endelig skal køre applikationer i internet enviroments, bruger man da alligevel ikke en virtuel maskine, vel?
De skriver også lidt om det her:
http://www.pcworld.com/article/id,137504-pg,1/arti...
#2: Hvorfor bruger man ikke virtualisering i "internet environments"?
http://www.pcworld.com/article/id,137504-pg,1/arti...
#2: Hvorfor bruger man ikke virtualisering i "internet environments"?
Ret lige overskriften:
"vitualisering" -> "virtualisering"
Jeg var i tvivl om det var en stavefejl af visualisering eller virtualisering, før jeg læste artiklen.
~
Hvad bruger man virtualisering til, professionelt? Jeg har selv Vista kørende på en Virtual PC, så længe Vista er for dårligt til at jeg vil have det som primært OS, men der er sikkerhedshuller sådan set ikke den store fare, da jeg ikke kører det så længe ad gangen, og jeg vil skide på vira.
Hvad bruger firmaer det til? Bruges det f.eks. til at hoste både Windows- og Linux-webhoteller på samme maskine?
Bare nysgerrig, siden det åbenbart er sådan en fare.
"vitualisering" -> "virtualisering"
Jeg var i tvivl om det var en stavefejl af visualisering eller virtualisering, før jeg læste artiklen.
~
Hvad bruger man virtualisering til, professionelt? Jeg har selv Vista kørende på en Virtual PC, så længe Vista er for dårligt til at jeg vil have det som primært OS, men der er sikkerhedshuller sådan set ikke den store fare, da jeg ikke kører det så længe ad gangen, og jeg vil skide på vira.
Hvad bruger firmaer det til? Bruges det f.eks. til at hoste både Windows- og Linux-webhoteller på samme maskine?
Bare nysgerrig, siden det åbenbart er sådan en fare.
#3: tipsen
Det gør man da i hvertfald! Tænk at du har en host, den hoster en masse gæste-systemer som kører lidt af hvert. Hvad kan bedst betale dig rent adminisrationsmæssigt der bliver hacket din host (med alle gæste-systemerne), eller en enkelt gæst der ikke ved noget om sikkerhed og derfor ikke har patchet op?
Selv kører vi Linux-Vserver på vores server og vi er en 6-7 gutter der deler den maskine. Men med dette projekt deler alle gæstesystemerne EN Linux kerne, men distributionerne varierer meget vi kan køre alt fra Debian til Gentoo på gæste-området. Så vi kan give folk hvad de vil have. Når de så forbinder til deres vserver så kan de ikke kende forskel på den og en dedikeret.
hvis man endelig skal køre applikationer i internet enviroments, bruger man da alligevel ikke en virtuel maskine, vel?
Det gør man da i hvertfald! Tænk at du har en host, den hoster en masse gæste-systemer som kører lidt af hvert. Hvad kan bedst betale dig rent adminisrationsmæssigt der bliver hacket din host (med alle gæste-systemerne), eller en enkelt gæst der ikke ved noget om sikkerhed og derfor ikke har patchet op?
Selv kører vi Linux-Vserver på vores server og vi er en 6-7 gutter der deler den maskine. Men med dette projekt deler alle gæstesystemerne EN Linux kerne, men distributionerne varierer meget vi kan køre alt fra Debian til Gentoo på gæste-området. Så vi kan give folk hvad de vil have. Når de så forbinder til deres vserver så kan de ikke kende forskel på den og en dedikeret.
#4
Det bruges til at samle services paa samme server, hvor man saa kan lave hotswap servere :)
Vi har 3 dell servere i et rackskab.. De koerer ~8 forskellige servere virtuelt, som saa automatisk kan flytte sig rundt paa de 3 dell-maskiner..
Hvis en af dem crasher, saa koerer det videre uden mere end 1 pakke tabt :)
Der er massere af fordele..
Den eneste ulempe er at VMware i sig selv har nogle sikkerhedshuller som kan bruges til at crashe maskinen fx.. :)
Det bruges til at samle services paa samme server, hvor man saa kan lave hotswap servere :)
Vi har 3 dell servere i et rackskab.. De koerer ~8 forskellige servere virtuelt, som saa automatisk kan flytte sig rundt paa de 3 dell-maskiner..
Hvis en af dem crasher, saa koerer det videre uden mere end 1 pakke tabt :)
Der er massere af fordele..
Den eneste ulempe er at VMware i sig selv har nogle sikkerhedshuller som kan bruges til at crashe maskinen fx.. :)
#6:
Lad os lige for det på det rene:
Hvis én af dine ESX servere crasher, så undgår du bestemt ikke pakketab (eller tab af service) på de VMs der kørte på pågældende ESX.
Det ESX (altså VI3) kan derimod er automatisk at starte dem automatisk op på en anden ESX.
Derudover understøtter ESX+VI3 at man kan foretage VMotion - dvs. flytte en kørende VM fra én ESX til en anden UDEN pakketab - men da kun hvis afgivende ESX og Modtagende ESX begge er kørende.
Mht. brug af Virtualisering generelt:
Sikring af en given ESX er ikke anderledes end sikring af en hvilken som helst anden tilfældig host - dvs. en dedikeret firewall op foran ud mod usikre zoner.
Derudover åbner man naturligvis ikke for de Portgroups ESX'en bruger til administration osv. til andet end et givent sikret netværk (management VLAN f.eks.) - det er jo ikke anderledes end et hvilket som helst andet system.
De huller der er blevet fundet hidtil har ikke haft noget kritisk at gøre med Virtuelle Netværk i de virtuelle maskiner, og kan derfor IKKE påvirke selve ESX'en såfremt ovenstående er overholdt.
Generelt et MEGET sikkert produkt.
Lad os lige for det på det rene:
Hvis én af dine ESX servere crasher, så undgår du bestemt ikke pakketab (eller tab af service) på de VMs der kørte på pågældende ESX.
Det ESX (altså VI3) kan derimod er automatisk at starte dem automatisk op på en anden ESX.
Derudover understøtter ESX+VI3 at man kan foretage VMotion - dvs. flytte en kørende VM fra én ESX til en anden UDEN pakketab - men da kun hvis afgivende ESX og Modtagende ESX begge er kørende.
Mht. brug af Virtualisering generelt:
Sikring af en given ESX er ikke anderledes end sikring af en hvilken som helst anden tilfældig host - dvs. en dedikeret firewall op foran ud mod usikre zoner.
Derudover åbner man naturligvis ikke for de Portgroups ESX'en bruger til administration osv. til andet end et givent sikret netværk (management VLAN f.eks.) - det er jo ikke anderledes end et hvilket som helst andet system.
De huller der er blevet fundet hidtil har ikke haft noget kritisk at gøre med Virtuelle Netværk i de virtuelle maskiner, og kan derfor IKKE påvirke selve ESX'en såfremt ovenstående er overholdt.
Generelt et MEGET sikkert produkt.
Kan de, hvis intellektuelle niveau er på: "Skaldemand? Nah, det kan jeg sgu ikke finde ud af" og derfor får jobbet: "Her Ryan (tilfældig indsat navn) - dit nye arbejde! Du skal bare sidde og læse de her chatsamtaler fra arto igennem - og så må du gå hjem klokken 15. Hvis du bliver færdig før tid, så tager du bare fat på jubii-chatten, så får du måske før fri i morgen. Hvis du ser noget mistænkeligt, slår du så ikke lige på tråden?" - er de i stand til ikke at slå alarm ved mine til tider satiriske og ironiske chatsamtaler, der af og til tager overhånd? og kan de arabisk?
#1
Når man taler virtualisering og sikkerhed er virtualiseringslaget meget mere kritisk end det OS der køre i de virtuelle guests.
Har man idag fysisk adgang til en server kan man stort set altid gennemtvinge sig adgang til maskinen og kontrol over den.
Hacker man VMware og kan "kopiere" de virtuelle maskiner,og så er den fysiske sikerhed brudt.
Netop af denne årsag vælger mange virksomheder fornuftigt nok at undlade at virtualisere deres DC'ere.
Dette problem bliver delvist løst med Windows Server 2008 der tilbyder mulighed for at kryptere det nederste lag med BitLocker og at installere DC'erne som Read Only (RODC), der gør det muligt at have DC'ere der ikke har en lokal kopi af databasen men blot cacher informationen i memory.
Når Windows Server frigives (Q1 2008), forventes det at mange branch offices vil blive installeret med disse teknologier for at kompensere for den fysiske adgang.
Næste generations virtualisering placeres i en ROM på hardwaren, og skal formentlig opdateres som en BIOS opdatering. Dette vil give et ultra tyndt lag sammenlignet med det vi kender i dag. Dette vil også gøre det muligt at lave hardware appliance bokse, som vi kender det med NAS og andre storage bokse. Og det vigtigste... performance vil formentligt være 99% så hurtigt som "rent" hardware.
/Ronni
Windows har også sikkerhedshuller (mange) men det gør ikke at jeg lader være at bruge windows.
Når man taler virtualisering og sikkerhed er virtualiseringslaget meget mere kritisk end det OS der køre i de virtuelle guests.
Har man idag fysisk adgang til en server kan man stort set altid gennemtvinge sig adgang til maskinen og kontrol over den.
Hacker man VMware og kan "kopiere" de virtuelle maskiner,og så er den fysiske sikerhed brudt.
Netop af denne årsag vælger mange virksomheder fornuftigt nok at undlade at virtualisere deres DC'ere.
Dette problem bliver delvist løst med Windows Server 2008 der tilbyder mulighed for at kryptere det nederste lag med BitLocker og at installere DC'erne som Read Only (RODC), der gør det muligt at have DC'ere der ikke har en lokal kopi af databasen men blot cacher informationen i memory.
Når Windows Server frigives (Q1 2008), forventes det at mange branch offices vil blive installeret med disse teknologier for at kompensere for den fysiske adgang.
Næste generations virtualisering placeres i en ROM på hardwaren, og skal formentlig opdateres som en BIOS opdatering. Dette vil give et ultra tyndt lag sammenlignet med det vi kender i dag. Dette vil også gøre det muligt at lave hardware appliance bokse, som vi kender det med NAS og andre storage bokse. Og det vigtigste... performance vil formentligt være 99% så hurtigt som "rent" hardware.
/Ronni
#11 Nu kører vores ESX-bokse på en Redhat, så den er vel ikke mere hullet, end hvad en Redhat nu har af huller, og mig bekendt giver fysisk adagang til ESX-boksen ikke flere muligheder for at stjæle data, end hvis maskinerne havde været fysiske?
Jeg forstår slet ikke din argumentation.
Har du fysisk adgang til fysiske maskiner, kan du lukke dem ned, og kopiere data fra harddiskene eller hvad du nu vil.
Har du fysisk adgang til en ESX-boks, skal du enten hacke RedHat'en, eller ligesom ovenfor lukke ned og kopiere harddiskene.
Jeg ser ikke det store sikkerhedshul der - forklar dem venligst så jeg forstår det. :)
Iøvrigt giver det ikke meget mening at virtualisere sine DC'er.
Generelt om virtuelle maskiner, skal det siges at de kører på delte ressourcer, så IO eller CPU-tunge maskiner, forsøger man at ligge på dedikerede servere.
Oversat betyder det, at dine databaseservere, dine filservere, dine tunge beregnings-servere, dine applikations-servere dine DC'er lader du kører på egen maskine, hvorimod dine småservere, hvad du nu har af test-servere, muligvis dine web-servere og andet hvor belastningen er relativ lille, dem kan du gøre virtuelle.
Det sidste du skrivre er jeg heller ikke helt med på.
Ideen i at virtualisere sine servere, er jo at man kan deles om HW - uanset hvor dit emulerings-software befinder sig, vil du stadig kører på delte ressourcer.
Jeg påstår ikke dit indlæg er spækket af fejl, jeg tror bare der er nogle ting som jeg ikke helt forstår i dit indlæg! :-)
Links please!
Jeg forstår slet ikke din argumentation.
Har du fysisk adgang til fysiske maskiner, kan du lukke dem ned, og kopiere data fra harddiskene eller hvad du nu vil.
Har du fysisk adgang til en ESX-boks, skal du enten hacke RedHat'en, eller ligesom ovenfor lukke ned og kopiere harddiskene.
Jeg ser ikke det store sikkerhedshul der - forklar dem venligst så jeg forstår det. :)
Iøvrigt giver det ikke meget mening at virtualisere sine DC'er.
Generelt om virtuelle maskiner, skal det siges at de kører på delte ressourcer, så IO eller CPU-tunge maskiner, forsøger man at ligge på dedikerede servere.
Oversat betyder det, at dine databaseservere, dine filservere, dine tunge beregnings-servere, dine applikations-servere dine DC'er lader du kører på egen maskine, hvorimod dine småservere, hvad du nu har af test-servere, muligvis dine web-servere og andet hvor belastningen er relativ lille, dem kan du gøre virtuelle.
Det sidste du skrivre er jeg heller ikke helt med på.
Ideen i at virtualisere sine servere, er jo at man kan deles om HW - uanset hvor dit emulerings-software befinder sig, vil du stadig kører på delte ressourcer.
Jeg påstår ikke dit indlæg er spækket af fejl, jeg tror bare der er nogle ting som jeg ikke helt forstår i dit indlæg! :-)
Links please!
#12
DC'ere laver sjældent ret meget, så de er perfekte at virtualisere. At det er pga. sikkerheden at man fravælger virtualisering af DC'ere er ikke sandt. Der er langt vigtigere overvejelser i den henseende.
Det eneste immidiære problem med virtualisering af DC'ere er FSMO rollen PDC Emulator pga. dens tidsmæssige afhængigheder. Da en VM ikke har adgang til rigtigt hardware og dermed ikke har direkte adgang til CMOS og dennes HW clock, vil tiden stille og roligt skride på maskinen, og da PDC Emulatoren er defacto Tidsserver i Domænet, vil andre servere's tid også skride. Dette kan sagtens fikses (bla. ved VMware tools), men det er en overvejelse.
Faktisk er en virtuel DC i domænet perfekt, da dette giver langt hurtigere DR muligheder - Restore af en fysisk DC er faktisk noget lort, men af en virtual bliver det LANGT nemmere da der ikke er HW afhængigheder.
Normalt anbefaler jeg dog at man har mindst én fysisk DC.
Tunge servere såsom Database, BI osv. kan SAGTENS virtualiseres - det skal bare gennemtænkes og designes rigtigt.
På det seneste med 4-kerne processorer, er det i allehøjeste grad blevet SÅ meget lettere og billigere at virtualisere - også "tunge" servere.
Det største performancemæssige problem pt. med VMware er den I/O mæssige side af sagen. Som det er nu anbefaler VMware selv at man ikke virtualiserer servere der har en højere I/O mængde end 1000 I/O pr. sekund. Men det er nu altså ret meget, og som SAN osv. pt. bliver bedre og bedre til at håndtere simultane I/O skulle det nok blive forbedret inden længe...
Mht. til sikkerhed, så har Ronni (#11) fuldstændig ret i at der er nogle overvejelser her der skal gøres. For det øjeblik du virtualiserer, får man pludselig også IP adgang til ens "hardwarelag" - dvs. det samme som fysisk adgang til en given server, men nu remote. Og det er altså en forværring ift. hvad større installationer har (IP KVM switche osv. kan self. også være et issue her...).
DC'ere laver sjældent ret meget, så de er perfekte at virtualisere. At det er pga. sikkerheden at man fravælger virtualisering af DC'ere er ikke sandt. Der er langt vigtigere overvejelser i den henseende.
Det eneste immidiære problem med virtualisering af DC'ere er FSMO rollen PDC Emulator pga. dens tidsmæssige afhængigheder. Da en VM ikke har adgang til rigtigt hardware og dermed ikke har direkte adgang til CMOS og dennes HW clock, vil tiden stille og roligt skride på maskinen, og da PDC Emulatoren er defacto Tidsserver i Domænet, vil andre servere's tid også skride. Dette kan sagtens fikses (bla. ved VMware tools), men det er en overvejelse.
Faktisk er en virtuel DC i domænet perfekt, da dette giver langt hurtigere DR muligheder - Restore af en fysisk DC er faktisk noget lort, men af en virtual bliver det LANGT nemmere da der ikke er HW afhængigheder.
Normalt anbefaler jeg dog at man har mindst én fysisk DC.
Tunge servere såsom Database, BI osv. kan SAGTENS virtualiseres - det skal bare gennemtænkes og designes rigtigt.
På det seneste med 4-kerne processorer, er det i allehøjeste grad blevet SÅ meget lettere og billigere at virtualisere - også "tunge" servere.
Det største performancemæssige problem pt. med VMware er den I/O mæssige side af sagen. Som det er nu anbefaler VMware selv at man ikke virtualiserer servere der har en højere I/O mængde end 1000 I/O pr. sekund. Men det er nu altså ret meget, og som SAN osv. pt. bliver bedre og bedre til at håndtere simultane I/O skulle det nok blive forbedret inden længe...
Mht. til sikkerhed, så har Ronni (#11) fuldstændig ret i at der er nogle overvejelser her der skal gøres. For det øjeblik du virtualiserer, får man pludselig også IP adgang til ens "hardwarelag" - dvs. det samme som fysisk adgang til en given server, men nu remote. Og det er altså en forværring ift. hvad større installationer har (IP KVM switche osv. kan self. også være et issue her...).
#15
Det var så lidt :-)
Mht. "har det bedre", så er jeg da fuldstændig enig heri, MEN igen skal man jo så overveje fordele mod ulemper, og i de fleste tilfælde har jeg dog stadig anbefalet en virtualisering - også i store miljøer.
DB'ere er jo som oftest ret vigtige for forretningen, og her vælger man fordelen ved VMware omkring hurtig disaster recovery, Snapshots og ikke mindst VMotion (herunder naturligvis Ha og DRS), op imod tab af en smule performance.
Naturligvis under hensyntagen til almindelig best practice og efter en grundig analyse af serveren(ne).
Det var så lidt :-)
Mht. "har det bedre", så er jeg da fuldstændig enig heri, MEN igen skal man jo så overveje fordele mod ulemper, og i de fleste tilfælde har jeg dog stadig anbefalet en virtualisering - også i store miljøer.
DB'ere er jo som oftest ret vigtige for forretningen, og her vælger man fordelen ved VMware omkring hurtig disaster recovery, Snapshots og ikke mindst VMotion (herunder naturligvis Ha og DRS), op imod tab af en smule performance.
Naturligvis under hensyntagen til almindelig best practice og efter en grundig analyse af serveren(ne).
At det er pga. sikkerheden at man fravælger virtualisering af DC'ere er ikke sandt.
Så du kender alle grunde til at fravælge at virtualisere DC'ere...
hmmm....
Jeg har kunder der ikke vil virtualsere deres DC'ere pga. sikkerheden. Det vigtigt for dem at sikre at en medarbejder eller en konsulent ikke lige "kommer til" at tage en kopi af en DC.
Det er en lang snak som vi kan fluekneppe over længe så derfor er der ikke grund til at køre den længere ud...
Tunge servere såsom Database, BI osv. kan SAGTENS virtualiseres - det skal bare gennemtænkes og designes rigtigt.
Igen... ikke alle...
Vi har en SQL installation bestående af 8 servere med 4 CPU'er i hver maskine og database og log filer fordelt på små 200 diske. Et virtualiserings lag vil ALTID reducere performance på IO.
Som du selv skriver senere er IO et problem, og store database servere og IO hænger ofte sammen...
Men.... satte vi os ned over en kop øl blev vi nu sikkert hurtigt enige... :o)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund