Tag Archives: Linux

Presentatie: Zarafa, van closed naar open

De onderstaande presentatie is gegeven als inleiding voor een workshop Zarafa. Hoewel de workshop “hands-on” was, is het belangrijk dat de deelnemers begrijpen wat nu precies de verschillen zijn tussen proprietary software en open source software. Deze presentatie gaat daarom in op de 5 wetmatigheden van de “digitale wereld”. Deze wetmatigheden zijn kort gezegd:

  1. Digitaal delen is vermenigvuldigen,
  2. Geen afnemend nut van kopieën,
  3. Kopiëren (of delen) tegen verwaarloosbare tijd en kosten,
  4. De economie van het delen en,
  5. Geen monopolie op de productiecapaciteit.

Daarnaast wordt ingegaan op de effecten hiervan op de muziek- en film industrie. Ook wordt uitgelegd wat het verschil is tussen producten maken, of diensten leveren en de gevolgen hiervan op de organisatie.

Deze presentatie is gehouden in september 2012, tijdens een Zarafa workshop die door Zarafa en Stone-IT is georganiseerd.

 

Puppet, hot or not?

Puppet is hot. Ik hoor van veel organisaties dat ze bezig zijn met een implementatie van Puppet of die overwegen. Verschillende van onze klanten zijn bijvoorbeeld bezig met de voorbereiding ervan. Toch is het interessant dat het nu zo populair wordt. Mijn collega’s gebruiken het al jaren voor het beheer van onze systemen. Maar blijkbaar is de tijd er nu ‘rijp’ voor.

Maar wat is Puppet? Het is management software waarmee grote aantallen servers beheerd kunnen worden. Het gaat hierbij zowel om het beheer van configuratie files (zeg maar instellingen van de servers) als het beheer van de geïnstalleerde software (packages). Een typische use case voor Puppet is bijvoorbeeld het beheer van virtuele servers in een cloud. Het kan dan gebruikt worden om snel extra webservers te installeren. In Puppet worden recepten (classes) gemaakt waarin de server feitelijk beschreven is.

Deze recepten kunnen ook dynamisch zijn doordat ze scripts bevatten die situatie afhankelijk software installeren. Zo kan een script testen op welk type hardware de installatie plaats vindt en aan de hand daarvan bepalen welke specifieke software (ten behoeve van ILO, DRAC et cetera) geïnstalleerd moet worden. Op iedere te beheren server draait een server proces (puppet.d) dat met de server communiceert. Deze communicatie is versleuteld en er kan ingesteld worden met welk interval de configuratie van de te beheren server vergeleken wordt met de Puppet server.

Ook kan gebruik gemaakt worden van Facter. Met Facter kan informatie van verschillende servers verzameld worden. Deze informatie kan eventueel samen met variabelen gebruikt worden in de recepten. De recepten zijn overigens te nesten zodat ze hergebruikt kunnen worden. Al met al een krachtig stuk gereedschap dat steeds krachtiger wordt naar mate er meer servers beheerd moeten worden. Een andere sterke kant is dat het volledig command line gebaseerd is. Maar de leercurve van Puppet is stijl. Een (open source) alternatief voor Puppet is CFengine.

Enthousiast

Een interessante vraag is waarom de technisch specialisten er zo enthousiast over zijn. Voor een deel is dit te begrijpen omdat technische mensen niet graag dubbel werk verrichten. Wanneer de eerste server is ingesteld en een tweede geconfigureerd moet worden, begint een technisch specialist na te denken of het niet slimmer kan. Puppet is een manier om het slimmer te doen en daar houden ze van. Natuurlijk moeten de recepten gemaakt worden en zonder twijfel wordt het daar complexer van. Maar bij grote aantallen servers scheelt het veel tijd. Daarnaast is een beetje complexiteit voor een technisch specialist een intellectuele uitdaging.

Een andere reden om Puppet te willen gebruiken is dat ze daarmee controle en overzicht verkrijgen. Middels de recepten zijn de configuraties van alle servers beschreven. Dat scheelt behoorlijk als er gedocumenteerd moet worden, een werkje dat niet altijd even leuk gevonden wordt. Bovendien kan eenvoudig de configuratie van honderden servers aangepast worden. Als technisch specialist ben je daarmee ‘in control’.

Als Puppet gecombineerd wordt met GIT kan er versiebeheer uitgevoerd worden op de configuraties. Het voordeel van dit versiebeheer is dat er een roll back kan worden gedaan naar een ‘oude’ configuratie waarvan bekend is dat die werkte en dat alle wijzigingen gedocumenteerd zijn. Er is precies te zien wie, wanneer, wat, heeft veranderd.

Een nog interessantere vraag is waarom bedrijven vanuit het business perspectief gebruik zouden willen maken van Puppet. It-organisaties zien zich tegenwoordig geconfronteerd met een aantal uitdagingen waarbij Puppet mogelijk kan helpen. Om te beginnen moet alles tegen lagere kosten. Met andere woorden het moet efficiënter. Dit is bij uitstek natuurlijk een gebied waarin Puppet zinvol gereedschap is. Mits goed ingericht kan met weinig mankracht een groot aantal servers worden beheerd.

Praktisch

Doordat alle configuraties beschreven zijn kunnen servers ook snel (fysiek danwel virtueel) opnieuw geïnstalleerd worden. Dit is buitengewoon praktisch wanneer een systeem bijvoorbeeld gehacked is. De enige manier om zeker te zijn dat alle ‘achterdeurtjes’ verwijderd zijn, is een herinstallatie uit te voeren. In Puppet is het gehele systeem beschreven waardoor ook de herinstallatie kan snel worden uitgevoerd. De aangewakkerde aandacht voor security de laatste tijd maakt dit een aantrekkelijke feature.

Indien Puppet gecombineerd wordt met GIT, zoals eerder aangegeven, kan historie worden bewaard. Dit betreft een historie van alle wijzigingen die er op servers hebben plaatsgevonden. Vanuit ITIL – een beheermethodiek die veel toegepast wordt – is dit erg interessant. De gedachte achter ITIL is dat 80 procent van alle verstoringen veroorzaakt worden door wijzigingen. Goede documentatie van alle wijzigingen is een eerste stap richting het beheersen en controleren van het veranderproces. Betere beheersing van het veranderproces leidt tot minder verstoringen. Het is duidelijk wat het belang van minder verstoringen is voor de bedrijfsvoering van organisaties.

Puppet is open source software. Dit maakt de instap bijzonder laagdrempelig. Indien organisaties behoefte hebben aan commerciële support dan kan deze onder andere bij Puppetlabs verkregen worden. Er kan dan gebruikt gemaakt worden van de enterprise edition. Deze betaalde versie heeft naast support ook extra’s die het goed bruikbaar maken binnen bijvoorbeeld een VMware-omgeving. In mijn ogen is de populariteit van Puppet wederom een voorbeeld waaruit blijkt dat Linux en open source software steeds meer main stream worden. Het is gereedschap om juist grote aantallen servers te beheren en dat betekent dat er dus grote aantallen Linux servers in gebruik zijn bij steeds meer organisaties.

Al met al prima redenen om het te gaan gebruiken, maar ik vraag me af of er ook redenen zijn om Puppet juist niet te gebruiken?
Dit artikel is verschenen op de site van Computable op 20-03-2012

Open source software helpt lekken voorkomen

Het zal je niet zijn ontgaan dat veel overheidsinstanties en gemeenten onder vuur liggen vanwege gebrekkige ict-beveiliging. Verschillende websites blijken gevoelig te zijn voor kwetsbaarheden en onvolkomenheden in de software waardoor de controle over sites kan worden overgenomen. Ook kunnen er gegevens buit gemaakt worden. Voor bedrijven en overheden levert dit imagoschade op.

In de media worden deze beveiligingslekken uitvoerig beschreven en naar buiten gebracht. Maar wat kan aan aan de beveiligingslekken gedaan worden. En, in relatie tot dit expert topic, welke rol kan open source software hierbij spelen?

Laat het duidelijk zijn, ict-security is iets dat niet alleen in de software kan geregeld kan worden. Security moet je op alle vlakken aanpakken, zowel procedureel, fysiek, op hardware als in de software (hierbij kan de software zelfs nog gesplitst worden in de applicatie en systeemsoftware zoals operating systeem, database en webserver). Zo’n integrale aanpak zorg ervoor dat je niet alleen de voordeur dichttimmert, maar ook de achterdeur goed vergrendeld.

In de meeste voorbeelden in de media zijn websites het doelwit. In mijn ogen is dit niet schokkend. In de meeste gevallen betreft het informatie die toch al met de buitenwereld gedeeld wordt. Ik zou het veel kwalijker vinden wanneer er informatie verkregen wordt die de betreffende organisatie of het bedrijf niet wilde delen. Het lijkt me dat je daarom data zou moeten classificeren, bijvoorbeeld in drie niveaus van vertrouwelijkheid. Op elk niveau kunnen passende maatregelen getroffen worden. Daarnaast zou bij zelfbouw van applicaties security in het design mee genomen moeten worden. Strikte regels en afspraken tijdens het programmeren helpen security risico’s te verkleinen of ze (later) eenvoudiger te verhelpen.

Wat mij in de meeste berichten opvalt is dat de sites al zo’n lange tijd ‘lek’ blijken te zijn. Dat suggereert dat de sites niet of niet goed beheerd worden. Of in ieder geval dat de beheerder niets in de gaten heeft gehad. Goed beheer is dan ook een erg belangrijke voorwaarde voor security. Een goede beheerder weet wat er zich op de systemen afspeelt. Hij (of zij) heeft bijvoorbeeld een adequate update policy. Software wordt regelmatig van updates voorzien en security updates worden met voorrang doorgevoerd. Het spreekt vanzelf dat kennis en ervaring noodzakelijk zijn voor goed beheer.

Maar kan open source software helpen? Voor wat betreft het software-deel kan dat naar mijn idee zeker. Er zijn verschillende open source softwaretools beschikbaar die gebruikt kunnen worden om de mate van security te verhogen. Nu zal je misschien denken, zijn dat niet dezelfde tools die ook door de hackers gebruikt worden? Dat zou best kunnen, maar in mijn ogen is dat juist een extra reden er kennis van op te doen en ze te gebruiken.

Prijskaartje

Vanwege de vaak lagere kosten kan open source software de financiële bezwaren wegnemen om dergelijke tools te gaan gebruiken. Geen aanschafprocedure en niet-techneuten die daarover moeten beslissen, gewoon downloaden. Open source-software is daardoor laagdrempelig. Veel van de tools maken ook nog standaard deel uit van een (Linux) distributie en dat maakt het gebruik nog eenvoudiger. Voorbeelden hiervan zijn Linux gebaseerde firewalls zoals Shorewall en bijvoorbeeld tcpdump waarmee het netwerkverkeer van een interface kan worden bekeken. In het verleden heb ik daar veel gebruik van gemaakt. Naar verloop van tijd wordt je handig in het gebruik ervan. Een ander mooi voorbeeld is SELinux. Dit is een systeem dat in veel Linux distributies aanwezig is en waarmee het systeem veiliger kan worden gemaakt. Met SELinux kunnen bijvoorbeeld de mogelijkheden van een server proces, zoals de webserver, om het filesysteem te benaderen geminimaliseerd worden. Indien de webserver gehackt zou worden, blijven de mogelijkheden dit te misbruiken beperkt. Ook denk ik aan Nessus, een open source netwerkscanner die het netwerk doorlicht op bekende kwetsbaarheden. Wat weerhoudt organisaties ervan dergelijk producten te gebruiken?

Is open source software zelf ook veiliger? Mogelijk, maar natuurlijk bevat ook open source software bugs en kwetsbaarheden, het is en blijft software. Wel weten we inmiddels dat ‘security by obscurity’ zoals in de commerciële software wereld gehanteerd wordt niet werkt. Juist openheid over security problemen leidt tot oplossingen en dus tot een veiliger systeem. Bovendien, al zou een oplossing (nog) niet beschikbaar zijn, zodra bekend is dat er een security probleem is, kan je als klant, eindgebruiker of beheerder maatregelen nemen. In het meest extreme geval sluit je een systeem van internet af. Je hebt in ieder geval de keuze.

Ook biedt open source software de mogelijkheid zelf het heft in handen te nemen. Zo werkt een collega van me aan Handshake, een sms-authenticatie portal dat gebruik maakt van OpenVPN. De portal regelt de ‘two factor security’ en OpenVPN de beveiligde netwerkverbinding. OpenVPN is open source software en Handshake wordt dat in de nabije toekomst. De combinatie van beiden is een goed alternatief voor commerciële software die het ‘thuiswerken’ ondersteunen.

Terug naar de vraag, kan open source software mijn ict-security helpen te vergroten? Ik ben van mening dat het dat zeker kan. Toch zal een goede aanpak zich niet beperken tot de software. Een beheerder die van mening is dat de webserver niet gehackt zal worden leeft in een fantasiewereld. Ga ervan uit dat het gebeurd en kijk dan nogmaals naar het systeem, neem security serieus en gebruik de goede tools. En als laatste, zorg voor een calamiteitenprocedure. Welke maatregelen ga jij nemen als je gehackt bent? Wie gaat de communicatie voor zijn rekening nemen? Denk hier goed over nu je daar nog rustig de tijd voor hebt.

Wat ik echter niet begrijp is dat er nog steeds bedrijven zijn die hacks ontkennen en eromheen draaien. Is het inmiddels niet duidelijk dat zoiets niet meer kan? Of vinden we security gewoon niet belangrijk?

Dit artikel is verschenen op de site van Computable op 10-11-2011