NGN weblogs: Martijn Bellaard

Help, mijn ISP gaat failliet

Martijn Bellaard — Thu, 02 Sep 2010 21:30:01 +0200

Elke zaterdag ligt de computable bij mij op de deurmat. Op de voorkant pronkt een artikel over Ipv6 “Deel ISP's gaat failliet aan IPv6”. Is me dat even schrikken, mijn ISP gaat dus failliet. Gelukkig lees ik verderop in het artikel dat dit niet geldt voor XS4all, want die werkt al met IPv6. En laat XS4all nu net mijn provider zijn.

Maar is het nu echt zo erg? Gaan de ISP's failliet? In ieder geval de ISP’s die niet bezig zijn met IPv6. Om antwoord op de vraag te geven of ze failliet gaan moet je eerst bepalen wat een ISP allemaal moet doen om IPv6 te kunnen leveren aan zijn klanten. Alles wat een ISP moet doen is te onderzoeken welke netwerk-infra onderdelen IPv6 ondersteunen. Hierbij denk ik aan de volgende netwerk-infra onderdelen:

Netwerkapparatuur, zoals routers, switches, firewalls, access point enz.
Operating systems, zoals Windows en Linux.
Services, zoals IIS, Apache, DNS, Citrix, SQL enz.
Applicaties, zoals Sharepoint, PHPnuke, enz.

Nu heb ik in het verleden al vaker onderzoek gedaan naar IPv6-readyness van verschillende onderdelen. Wat mij daarbij opviel is dat de meeste Operating systems, waaronder zeker Windows en Linux vallen, IPv6 ready zijn. Eigenlijk is de MAC de enige die niet officieel IPv6 ready is. Ook voor de netwerklaag geldt dat de meeste onderdelen IPv6 ready zijn. Alleen de firewalls blijven een beetje achter. Mijn grootste zorg zit hem in de services en applicatielaag. Hierin zie je hele verschillende resultaten. Zo zie je op de Citrix site de volgende vraag en antwoord: "Are Citrix products ready for a transition to IPv6?" is a good next question to ask, and the answer is YES, for the most part. Ja, bijna dus, maar niet helemaal. Net als de TMG. Deze begrijpt IPv6 en houdt IPv6-verkeer netjes tegen, maar doorlaten is een ander verhaal.

Mijn persoonlijke zorg zit hem dan ook niet direct bij de ISP's. Hun uitdaging voor de korte termijn zit hem in het maken van een ontwerp en het aanvragen van IPv6-range. Dan kunnen hun klanten ook over op IPv6. Maar de services en applicaties zijn van een hele andere orde. Persoonlijk denk ik dat we straks een heleboel problemen krijgen omdat applicaties niet klaar zijn voor IPv6. Als ze dat wel zijn, worden we eerst geconfronteerd met een heleboel bugs, voordat de applicatie net zo goed functioneert op IPv6 als op IPv4. Maar net als in het verleden zullen applicatieleveranciers hiervoor niet gestraft worden. Natuurlijk zullen ze klanten verliezen, maar failliet zullen ze er niet door gaan. En de ISP's. Die hebben straks een vollere call bak. Allemaal klanten die merken dat hun applicatie minder goed functioneert. Dat gaat hen zeker geld kosten en er ook zeker voor zorgen dat klanten minder tevreden zijn. Maar dat een klant snel wegloopt denk ik niet. Daarvoor is IT soms te complex.

Reacties (4)

Twitter, hebben we het echt nodig?

Martijn Bellaard — Wed, 25 Aug 2010 20:56:01 +0200

Langzaam is iedereen weer terug van vakantie. Het normale leven gaat weer beginnen. Ook mijn vakantie zit er weer op. Vorige week ben ik terug gekomen uit een land waar ze nauwelijks Engels spreken, laat staan dat ik er een Nederlandse krant kan vinden. Gelukkig vloog ik met een Nederlandse maatschappij terug en kon ik eindelijk weer een Nederlandse krant lezen. In dit geval was het de NRC. Nu kun je in een vliegtuig niet zoveel doen dus ik had alle tijd om de krant van voren naar achter door te lezen. Zeker gezien het feit dat mijn zoon op mijn schoot in slaap was gevallen en ik dus ook niet meer kon opstaan.

Op pagina 16 (Opinie) stond een intressant artikel van Arjen van Veelen.Dit artikel ging over de Zeven mythes van twitter (http://www.nrcnext.nl/blog/2010/08/17/omg-er-is-nieuws-flauwekul/ ):

1. Twitter is groot,

2. Trending Topics zijn belangrijk,

3. Twitter is een zegen voor de democratie,

4. Twitter is een zegen voor de journalistiek,

5. Snelheid is altijd goed,

6. Twitter is zelfreinigend,

7. Het is allemaal de schuld van twitter.

Nu kan ik alles wel herhalen, maar het artikel kun je ook zelf gaan lezen. Daarvoor heb ik de link toegevoegd. Wel is het dan interessant om te zien welke reacties er komen op het stuk. Ik was verbaasd op de heftigheid van sommige reacties. Net alsof de schrijver een dood zonde is begaan. De schrijver probeert Twitter te bagatelliseren, terwijl een aantal reacties duidelijk proberen te maken dat Twitter het helemaal is. Twitter is een nieuwe techniek, net als internet dat +/-30 jaar geleden was. Zoals je vaak ziet met nieuwe technieken zijn er voorstanders en tegenstanders. Zo is dat ook met twitter. Op dit moment staat deze techniek nog in zijn kinderschoenen en kunnen we ook nog niet zeggen hoe belangrijk het is. Wel kunnen we gaan kijken wat we er van kunnen gaan verwachten. Hiervoor zou je kunnen kijken naar de geschiedenis van Internet.

De reden voor het ontstaan van internet was de mogelijkheid om snel informatie uit te wisselen. Internet (of eigenlijk arpanet) moest er voor zorgen dat geleerden snel informatie konden uitwisselen. We zien dan ook in het begin dat er twee technieken zijn ontwikkeld om dit snel te kunnen doen. De eerste was email en de tweede was de website of HTML. De eerste techniek is een direct communicatie middel. Een middel waar we vandaag de dag niet meer omheen kunnen. Voor veel organisaties is email bedrijfskritisch informatie systeem. De tweede is bedoeld om informatie aan te bieden. Veel bedrijven beschikken dan nu ook over een website.

Ook zien we chatrooms op internet ontstaan. Hier kun je met verschillende mensen van gedachten wisselen over een onderwerp. Je kunt het zo gek niet bedenken of er is wel een chatroom voor. In het begin werden chatrooms vooral door particulieren gebruikt om lekker te “kletsen”. De functie van de chatroom wordt door bedrijven gebruikt om online meetings te houden, met of zonder een camera.

In 1998 ontstond er een nieuwe hype, ICQ. Dit was een stukje software waarmee je direct contact kon leggen met je vrienden. Op dat moment was het een tool voor mensen die geen vrienden hadden. Een tool die nooit verder zou komen als iets voor de thuis gebruikers. Niks is minder waar gebleken. Steeds meer bedrijven gaan gebruik maken van een Instant Messaging systeem.

HTML en email waren al vanaf het begin tijdperk van het internet, maar zijn tegenwoordig belangrijke onderdelen van bedrijfsprocessen geworden. IM en Chatrooms waren in de basis iets voor de thuis gebruiker, maar bedrijven zijn van deze technieken gebruik gaan maken om hun bedrijfsprocessen te ondersteunen. Binnen mijn eigen organisatie maken we gebruik van OCS. Dat is erg handig als je veel collega’s buiten Nederland hebt zitten.

Twitter is ook een nieuw fenomeen. Net als IM en de chatrooms wordt het in de eerste plaats gebruikt door een kleine club mensen. Thuis gebruikers die graag vertellen waar ze zitten en proffesionals om te laten zien wat ze doen. Tegenwoordig zien we dat steeds meer bedrijven en instellingen twitter gebruiken als communicatie medium.

Elke techniek voorziet in een speciale behoefte van mensen om te communiceren. HTML wordt gebruikt als een prikbord om informatie op te hangen. Email worden gebruikt om een “brief” aan iemand te sturen. IM wordt gebruikt om 1 op 1 te kunnen kletsen en chatrooms/live meetings worden gebruikt om gezamenlijk ergens over te praten.

Als we nu gaan kijken naar Twitter dan voorziet deze in een behoefte van mensen om iets te kunnen roepen. Dit doen ze om aandacht te krijgen voor hun zaak, zoals een marktkoopman dat doet op de markt. Ook hij roept maar wat in het rond en wil dan dat de mensen zijn waren komen kopen. Dit verklaart ook waarom veel mensen met een missie of visie op Twitter zitten. Denk hierbij aan iemand in de politiek. Twitter is een ideaal platform om kort en bondig je punt duidelijk te maken. Mensen te lokken om naar je te komen luisteren en dan ze (via html en/of email) de rest duidelijk te maken.

Maar ook het schreeuwen via een megafoon is iets wat je digitaal kan doen via twitter. Op die manier roep je iets in het wild en hoop je dat mensen er naar gaan luisteren. Denk hierbij aan een politieman die iedereen de opdracht geeft naar buiten te gaan.

Het succes van twitter gaat dus bepaald worden door hoeveel mensen zijn er die iets te vertellen hebben en hoeveel mensen willen er naar luisteren. Is het nuttig om via twitter te gaan roepen. Wel als je bedenkt dat, in het echte leven, mensen ook op een zeepkist gaan staan om hun standpunt duidelijk te maken. Het gevaar zit hem dan ook in dat mensen maar wat kunnen roepen. Iedereen kan op een zeepkist gaan staan en iets zeggen. Net als bij email/ HTML en IM zullen er mensen zijn die via twitter mensen gaan lokken om ze vervolgens op te lichten. Hoe twitter straks hiermee omgaat, zal ook het succes van twitter bepalen.

Reacties (1)

HTTPS inspection configuratie

Martijn Bellaard — Sat, 17 Jul 2010 14:55:01 +0200

In vorige blog heb ik al behandelt wat HTTPS inspection nu precies is. In deze blog wil ik de configuratie behandelen en de eventuele uitdagingen die je daarbij tegen gaat komen.

Config HTTPS Inspection

HTTPS Inspection is een onderdeel van de Web Access Policy. Je configureert het dan ook vanuit hier.

Selecteer als eerste Web Access Policy,
Onder Task kies je voor Configure HTTPS Inspection,
Onder General selecteer Enbale HTTPS inspection.

Je heb nu twee opties:

ð Inspect traffic and validate site certificate, alle HTTPS verkeer en het certificaat worden gecontroleerd
ð Do not inspect traffic, but validate site certificates. Blocks HTTPS traffic if certificate is not valid. Nu wordt alleen het certificaat gecontroleerd. Is deze niet geldig of incorrect wordt het SSL verkeer geblokkeerd. De TMG doet geen inspectie van de inhoud.

Aangezien HTTPS inspection al het SSL verkeer controleert door voor elke website een nieuw certificaat aan te maken zal de TMG moeten beschikken over een eigen root certificaat. Je kunt er voor kiezen om zelf een certificaat te maken (UsE Forefront TMG to generate a certificate) of een bestaande root certificaat te importeren (Import a certificate).

Onderaan staat dan nog een knop . Als je hierop drukt krijg je het scherm Certificate Deyployment Options. In dit scherm is het vooral van belang dat je moet bedenken hoe je het root certificaat bij je clients krijgt. Doe je dit niet, zul je je client standaard certificaten, gemaakt door de TMG, niet kunnen vertrouwen. Dit heeft dan tot gevolg dat ze geen enkele SSL website meer zullen vertrouwen. Je kunt kiezen uit twee opties:

Automatically through Active Directory, hierbij maakt de TMG gebruik van de Active Directory om het certificaat te distribueren:

Druk op
Geef een gebruikersnaam en wachtwoord van een account dat in de AD een certificaat mag publiceren.

Manually on each client computer, om met de hand het certificaat te distribueren

Druk op
Geef een bestands naam aan het certificaat en druk op

HTTPS inspection is nu geconfigureerd. Als een gebruiker nu naar een SSL website gaat zal de TMG dit verkeer onderscheppen, controleren en stuurt het versleuteld door naar de client.

Tuning HTTPS Inspection

Nu is HTTPS inspection niet een wonder middel dat je aanzet en al je SSL sites blijven dan goed werken. Je zult merken dat een aantal websites niet meer werken. Dit kun je eenvoudig oplossen door uitsluiten van een aantal website of hosts van HTTPS inspection.

We gaan eerst een Destination uitsluiten van HTTP inspection

Kies voor tabblad Destination Exceptions.
Selecteer Site Exempt from HTTPS Inspection
Vul de URL in van de destination die niet geïnspecteerd mag worden.

We kunnen er ook voor kiezen een client (PC) uit te sluiten van HTTPS Inspection. Let hierbij op dat geen enkel SSL website meer gecontroleerd wordt. Het is beter om een destination uit te sluiten

Kies voor tabblad Source Exceptions.
Selecteer de juiste computer of computer set.

Nu kunnen we gaan aangeven wat er gecontroleerd moet worden van een certificaat.

Kies voor tabblad Certificate Validation.
Je kunt nu aangeven hoe oud een verlopen certificaat mag zijn, wat te doen met certificaten die nog niet actief zijn en of de CRL lijst gecontroleerd moet worden.

Het laatste tabblad is de Client Notification. Hier kun je aangeven of de gebruiker op de hoogte gesteld wordt dat zijn SSL website gecontroleerd word. Alleen als de gebruiker beschikt over de Proxy client zal hij deze melding zien.

Afsluiting

In deze blog heb ik behandeld hoe je HTTPS inspection moet configureren. Als je deze optie gaat gebruiken, en ik adviseer dat ook, maak dan eerst een lijst van de top 10 SSL websites. Deze kun je dan in de Exceptions lijst zetten.

Reacties (1)

Configureren IPv6 on Linux

Martijn Bellaard — Thu, 08 Jul 2010 20:07:01 +0200

In deze blog wil ik stil staan hoe je Ipv6 op Linux configureert. Bij Linux is de uitdaging dat er verschillende distributies zijn en niet elke distributie heeft standaard IPv6 aan staan. Dit zul je dus eerst moeten controleren.

Controleren op IPv6

Voordat we dus overgaan tot de configuratie, controleren we eerste of we IPv6 hebben. Als eerste moet er worden gekeken of de kernel IPv6 ondersteunt. Dit doe je op de volgende manier:
Commando: LS /proc/net/if_*
Als antwoord moet je if_inet6 zien. Is dit niet het geval dan is er geen IPv6-support aanwezig in de kernel en zal je een nieuwe kernel moeten maken met IPv6-support of de IPv6-module laden. Het laden van de module kun je doen met:
Commando: modprobe ipv6.

Er zijn een aantal utilities die noodzakelijk zijn voor de configuratie van IPv6:

· ifconfig, voor het configuren van de interface.

· route of ip, voor het opzetten van een router-entry.

· ping6 en traceroute6, standaard IP-utilities.

Met de volgende commando’s kun je controleren of de belangrijkste utilities IPv6 ondersteunen. Is dit niet het geval dan zul je eerst IPv6-ondersteuning van deze utilities moeten regelen.

Commandos:

- /sbin/ifconfig -? 2>& 1|grep -qw 'inet6' && echo "utility 'ifconfig' is IPv6-ready"
Utility ‘ifconfig’ is IPv6 ready

- /sbin/route -? 2>& 1|grep -qw 'inet6' && echo "utility 'route' is IPv6-ready"
Utility 'route' is IPv6-ready

- /sbin/ip 2>&1 |grep -qw 'inet6' && echo "utility 'ip' is IPv6-ready" (Optioneel)
utility 'ip' is IPv6-ready

- Ping6
Als Ping6 aanwezig is krijg je de help van Ping6

- Traceroute6
AlsTraceroute6 aanwezig is krijg je de help van traceroute6
Krijg je ergens een foutmelding of niets terug, dan is de ondersteuning voor IPv6 niet aanwezig en zul je dit eerst moeten regelen.

Configureren van het IP-nummer

Het configureren van een IP-nummer kun je doen met Ifconfig. Het commando hiervoor is: Ifconfig interface inet6 add IPv6-nummer/Prefix

Voorbeeld: Ifconfig eth0 inet6 add 2001:1:1:1::1/64

Na het configureren van het IP-nummer moet je nog opgeven wat de default gateway is. Het commando hiervoor is: route –A inet6 add ::/0 gw IPv6-adres van de default gateway metric 1 interface.

Voorbeeld: route –A inet6 add ::/0 gw 2001:1:1:1::11 metric 1 eth1

IPv6 Test Script

/sbin/ifconfig -? 2>& 1|grep -qw 'inet6' && echo "utility 'ifconfig' is IPv6-ready"
/sbin/route -? 2>& 1|grep -qw 'inet6' && echo "utility 'route' is IPv6-ready"
/sbin/ip 2>&1 |grep -qw 'inet6' && echo "utility 'ip' is IPv6-ready" (Optioneel)

Reacties (1)

IPv4 Exhaustion Counters

Martijn Bellaard — Tue, 25 May 2010 20:56:01 +0200

Dat IPv4 opraakt is weten we al, maar waarneer dan. Dit veschilt van dag tot dag en er is dus niet een vaste dag aan te wijzen. Hoe kom je er dan achter ..................... door elke dag te kijken ;-).

Maar wie wil nu elke dag (laat staan elke uur) kijken hoeveel Ipv4 nummers er nog zijn, buiten mij om dan ;-). Gelukkig heeft Hurricane Electric hier iets op gevonden. Ze hebben een aantal counters/gadgets gemaakt waaronder eentje voor Windows 7.

Installatie gadget.

Stap 1) Download de gadget (http://ipv6.he.net/statistics/)
Stap 2) Pak de zipfile uit naar directory “v4Exhaustion.Gadget”
Stap 3) Kopieer deze directory naar “C:\Program Files\Windows Sidebar\Gadgets”
Stap 4) Zorg dat je nu je desktop ziet, rechtermuisknop è Gadgets
Stap 5) Kies nu de gadget “Bye Bye v4” en plaatst deze ergens op de desktop.
Vanaf nu kun je precies zien hoeveel dagen je nog hebt voor je Ipv6 implementatie.

Martijn Bellaard

Reacties (1)

Cloud computing: to be or not to be?

Martijn Bellaard — Mon, 28 Jun 2010 11:32:01 +0200

Afgelopen week was dan het eerste Experts Live event. Ik mocht tijdens dit event weer optreden als een van de sprekers en na afloop was er voor de sprekers een klein etentje. Tijdens dit eten zat ik met een aantal medesprekers aan één tafel. Het gesprek ging dan ook al snel over de moderne technieken, waaaronder natuurlijk cloud computing. Één van mijn tafelgenoten was er helemaal van overtuigd dat over 5 jaar iedereen werkt vanuit de cloud, net zoals we stroom afnemen bij een stroom leverancier.

Nu is het vrij normaal dat we in computerland proberen vergelijking te trekken met voorwerpen uit ons dagelijkse leven. Zo hoor je regelmatig de vergelijk tussen een Operating System en een auto, internet en de snelweg en dus nu tussen cloud computing en andere diensten, zoals geld zaken en nuts bedrijven. In de blog wil ik eens dieper in gaan op deze vergelijkingen. Hoe houden ze stand en waarop lopen ze stuk. Vandaar uit wil ik kijken wat we er van kunnen leren en wat Cloud computing ons gaat brengen.

ICT vandaag de dag

Voordat je kunt gaan kijken hoe goed een vergelijking is zul je eerst een basis moeten bepalen. Aangezien we het over ICT hebben wil ik dus eerst helder krijgen hoe een ICT omgeving er vandaag de dag uit ziet. Nu wil ik geen groot onderzoek doen, dus ik zal uitgaan van mijn eigen observaties.

Ik maak een onderscheid tussen 4 type ICT omgevingen:

- klein, dit zijn organisaties met minder dan 50 werknemers. In dit soort ICT organisaties zie je vaak een SB server. Als ICT belangrijk is wil deze SB server nog wel eens vervangen worden door drie of vier servers. Het beheer van deze server wordt vaak door een externe partij gedaan.

Deze organisaties maken vaak gebruik van een aantal standaard applicaties, waaronder een Office pakket en een CRM-achtig pakket. Daarnaast kom je hier ook de benodigde “tooltjes” tegen en branche specifieke appalicaties.

- middelgroot , dit zijn organisaties met 50 tot 205 werknemers. Deze organisaties beschikken vaak over een eigen ICT afdeling die verantwoordelijk is voor de gehele ICT omgeving. Deze ICT omgeving bestaat uit meerdere servers. De trent in deze omgeving is om steeds meer zaken te standariseren, te automatiseren, en te professionaliseren.

Deze organisaties maken naast de standaard applicaties ook gebruik van een aantal afdeling- of branche specifieke applicaties. Daarnaast hebben ze een op maat gemaakte CRM, ERP, HRM enz, pakketten.

- groot, dit zijn organisaties met 205 tot een paar duizend werknemers. Deze organisaties beschikken vaak over een eigen “hosting” centrum, die in sommige gevallen intern aanwezig is, maar steeds vaker bij een hosting partij geplaatst wordt. Ook in deze omgevingen is de trend om steeds meer zaken te standariseren, te automatiseren, en te professionaliseren.

Ook bij deze organisatie zie je veel “maatwerk” op het gebied van ERP,CRM enz.

- Multinationals, dit zijn organisaties met 100.000 of meer werknemers. In dit soort organisaties is de ICT een bedrijf in een bedrijf geworden, waar vaak strakken afspraken en regels zijn om iets te kunnen doen of aan te passen binnen de ICT omgeving.

Hoe groter de omgeving hoe meer “maatwerk” we vinden. Veel organisaties maken gebruik van maat software voor hun dagelijkse werkzaamheden en het is daardoor één van de core applicaties geworden. Om het nog erger te maken zien we vaak dat dit maatwerk ook door een dhz-er gemaakt (dhz=doe het zelver) is. Dit is software die niet volgens de juiste standaards gemaakt is en veel problemen kent. Gelukkig zien we dan ook dat steeds meer organisaties bezig zijn deze software uit te faseren.

Daarnaast bevat veel software bedrijfsgevoelige gegevens. Gegevens dit niet buiten de organisatie bekend mogen worden. Gebeurd dat wel dan kan dit een bedrijf ernstige schade toebrengen. Dit is dan ook de grootste angst die de meeste organisaties hebben als er wordt gesproken over cloud computing.

De vergelijkingen

Nu we een uitgangspunt hebben bepaald kunnen we eens gaan kijken naar de verschillende vergelijkingen en hoe ze overeind blijven als we ze verder door spitten.

Cloud en Electriciteit

Electriciteit gebruiken we allemaal. Ergens komt het ons huis binnen (meestal de meterkast). We vragen ons eigenlijks nauwelijks af waar het vandaan komt en of het de juiste kwaliteit is. Daarnaast kunnen we kiezen tussen de smaken 220, 220 of 220. De vergelijking klopt als we er vanuit gaan dat we niet geinteresseerd zijn hoe we bij onze applicatie en data komen, zolang het er maar is. Maar het grootste manco met deze vergelijking zit hem in de keuze. Stroom kent maar één smaak, dit geldt niet voor een applicatie. Ten eerste hebben we een heleboel verschillende type applicaties en kent elke type soms ook nog meerdere merken. De enige overeenkomst tussen ICT en stroom is dat ICT stroom nodig heeft.

Cloud en Bank

De bank beheert ons geld. Met geld betalen we alles wat we gebruiken en nodig hebben. Als we ons geld kwijt raken komen we in ernstige problemen. Daarnaast zijn er veel vormen van sparen, beleggen en lenen. Hier zijn inderdaad een aantal overeenkomsten te vinden. Gevoelige data mag niet kwijt raken, net als ons geld. Een bank vertrouwen we al jaren met ons geld, waarom zouden we dan niet een ander organisatie vertrouwen met onze data!? Net als de vele vormen van sparen, beleggen en lenen hebben we veel verschillende applicaties. Dus een cloud zal al in de toekomst dus veel verschillende applicaties moeten aanbieden. Maar een bank kent ook maatwerk, maar dan moet je met veel geld komen. Kom je met een klein beetje geld, zeg een €10.000, dan zullen ze niet snel maatwerk voor je willen leveren. We hebben meer kans dat ze iets willen doen als we met een €100.000 of een paar nulletjes meer komen. Dit zullen we ook zien bij cloud computing.

Cloud en verzekeringen

De derde vergelijking is dit van verzekeringen en cloud. We betalen een verzekeraar regelmatig geld om er voor te zorgen dat we in geval van nood beschikken over wat extra geld. Net als bij een bank kennen we verschillende types en smaken. Maar een verzekering is in de eerste plaats voor nood en als we gebruik maken van cloud computing is dit niet voor nood. De enige twee overeenkomsten zit hem in vertrouwen en over data beschikken in geval van nood.

Conclusie

De beste overeenkomst zit hem tussen bank/verzekeringen en cloud. We zullen de cloud net zo moeten gaan vertrouwen als onze bank. We geven al onze gegevens aan een cloud. Deze slaat onze gegevens veilig op en zorgt er voor dat we er overal bij kunnen. Daarnaast zijn we er van verzekerd, net als bij verkeringen, dat we altijd bij onze gegevens kunnen. Ook in geval van nood.

Wat gaat het dus worden.

De geschiedenis van het bank/verzekerings wezen vertelt ons ook wat we kunnen gaan verwachten van cloud computing. In het begin waren mensen ook sceptisch tegenover een bank. Alleen rijke mensen brachten hun geld naar de bank. Langzaam veranderde dit. Ik weet nog in mijn jeugd hoe mijn moeder 1x per maand naar de bank ging. Vaak een paar dagen nadat het salaris van mijn vader gestort was. Ze haalde dan enkele honderden guldens op. Dit geld werd thuis verdeeld over de verschillende potjes in een geld kistje. Alle lopende rekeningen werden daaruit betaalt.

Ook ik heb nog steeds die potjes, maar die staan nu in een excel sheet. Geld halen, doen we eigenlijk niet meer. Als ik ergens naar toe moet waar ik met “echt” geld moet betalen moet ik van tevoren er om denken om geld uit de muur te trekken. Ik heb eigenlijk nooit geld op zak. Ik betaal alles met mijn pas.

Dit is wat we ook zullen gaan zien met de cloud. Grote organisaties hebben vaak al hun eigen cloud. Bij midden en kleine organisaties draaien nog veel servers lokaal. In het begin zullen vooral standaard applicaties verhuizen naar de cloud. De belangrijkste data zal nog steeds in huis beschikbaar zijn op een lokale server (geld kistje). In de toekomst zal ook deze data beschikbaar worden in de cloud. We zullen dan met een device (pasje) onze data ophalen als we het nodig hebben.

Reacties (1)

IPv6, hoe overtuig ik mijn collega’s?

Martijn Bellaard — Fri, 14 May 2010 15:58:01 +0200

Ik merk dat steeds meer en meer systeem beheerders overtuigt raken van de noodzaak van IPv6. Dat is een goede zaak, maar dan zijn we er nog niet. Een systeem beheerder is vaak technisch verantwoordelijk voor de ICT infrastructuur, financieël is dit vaak iemand anders. Daarnaast heeft een systeem beheerder in een wat grotere organisatie ook nog te maken met collegas van verschillende afdelingen. In een doorsnee ICT afdeling kun je dus een onderscheid maken tussen de volgende drie type “beheerders”:

Een systeembeheerder
Een applicatie beheerder
Een manager

Nummer 1 heeft dus nu de schone taak om nummer 2 en 3 te overtuigen van het nut van IPv6. Hoe kun je dat nu het beste doen?

Wensen, eisen en focus gebied

Voordat we kijken hoe we nummer 2 en 3 kunnen overtuigen is het goed om eerst stil te staan bij hun wensen, eisen en het focus gebied. Deze zijn namelijk anders dan die van nummer 1.

De applicatie beheerder

Een applicatie beheerder heeft zijn primaire focus liggen op zijn applicatie. Deze moet goed functioneren en door gebruikers benaderbaar zijn. Het netwerk valt buiten zijn kennisgebied. Hij ziet dit als een soort wolk die er voor zorgt dat een gebruiker de gegevens kan benaderen. Deze wolk wordt door de systeem beheerder beheerd en in de ogen van de applicatie beheerder ligt dus daar de verantwoording. Als er problemen zijn met het netwerk dan went hij zicht tot de systeem beheerder en verwacht dat hij het probleem oplost.

Als je dus begint over IPv6 zal hij als eerste zeggen; “snap het niet, maar mijn beheerder moet het oplossen. Het is zijn probleem”. Deze houding is begrijpbaar, maar niet helemaal correct. Als je dus met hem in discussie gaat zul je dit eerste moeten takkelen. Vraag hem of de gebruiker over het netwerk praat met zijn applicatie. Meestal zal het antwoord ja zijn. Leg hem uit dat dit verkeer invloed heeft op de performance van het netwerk en dat hij dus zeker wel invloed heeft op het goed functioneren van het netwerk.

Als je hem dus nu aan jou kant hebt, hij vindt het netwerk nu ook iets wat zijn aandacht verdiend, kunnen we aan de slag met IPv6. Leg hem uit dat elke server en Workstation een IP nummer/telefoon- nummer heeft en dat die nummers gebruikt worden voor communicatie. Daarna ga je in op het feit dat de nummers opraken en dat het ook snel gaat. Leg hem vervolgens uit dat als de nummers op zijn, niemand meer naar zijn applicatie kan gaan. De oplossing voor dit probleem is …………………… IPv6.

Als hij overtuigt is dat er aandacht moet worden besteed aan IPv6 kun je hem nu overhalen dat ook HIJ aan de slag moet. Je kunt hem nu gaan vertellen dat IPv4 32 bits nummers heeft. Zijn applicatie is geschreven voor IPv4 en kan dus overweg met 32 bits nummers. IPv6 is een 128 bits nummer. Zijn applicatie kan waarschijnlijk hiermee niet overweg. Dit zal dus getest moeten worden.

Nu zijn we aangekomen op het punt om samen met de applicatie beheerder een test plan te gaan maken voor de IPv6 implementatie. L et op, waarschijnlijk zal de applicatie de eerste keer niet of slecht werken. Je ziet dat men dan snel IPv6 de schuld geeft. Leg hem uit dat niet IPv6 fout is, maar er iets mis is met de applicatie. Ik gebruik hiervoor vaak de volgende vergelijking:

Omdat we veel files in Nederland hebben heeft Den Haag besloten de A2 grondig te verbouwen. Als ik nu over de A2 rijd raakt mijn navigatie system van slag. Wie is er nu “fout”? A2 (IPv6) of mijn navigatie (de applicatie)?

De manager

De focus van de manager is weer anders dan die van de applicatie beheerder. Afhankelijk van de organisatie en functie zal de manager dichterbij de techniek of juist verder weg staan van de techniek. Gaat het om een manager die dicht bij de techniek staat kun je een heel eind aan de slag met de standaard IPv6 redenen, maar als de manager verder weg van de techniek staat, hebben technische redenen geen enkele zin.
De focus van deze manager zal op de volgende gebieden liggen:

Afspraken/SLA’s met de organisatie moeten worden nageleefd. Dit raakt zowel functionaliteit als stabiliteit
De kosten voor het beheer moet binnen het budget blijven
Een “verstandige” manager zal zeggen dat hij liever werkt met “proven technology”. Voor mij persoonlijk staat deze uitdrukking gelijk aan, “ik blijf liever dom en stom en ga me vooral niet ontwikkelen. Stel je eens voor dat ik moet werken of nog erger studeren”. Maar hiermee zul je waarschijnlijk niet ver komen bij je manager. Meestal werken ze namelijk al erg hard. De reden dat veel managers niet direct met nieuwe technieken willen werken is dat ze bang zijn dat hierdoor verstoringen optreden in de dienstverlening en ze dus hun afspraken niet kunnen nakomen. Een geheel terechte zorg. Daarnaast kosten nieuwe technieken ook altijd iets en lopen ze het risico dat ze een budget overschrijding krijgen. Als je ze dus wilt overtuigen van IPv6 zul je hiermee aan de slag moeten.

De SLA

IPv6 is dan wel een nieuwe techniek, maar we kunnen juist met deze motivatie goed aan de slag. Als eerste leggen we het telefoon verhaal voor en de bijbehorende oplossing, IPv6. Daarna wijzen we hem op de SLA’s. Maak hem hierbij duidelijk dat ook jij deze wil naleven en dat je in de toekomst problemen ziet. Als straks de nummers op zijn en wij dus niet op tijd er bij waren, we dus niet onze SLA’s kunnen nakomen. Door op tijd te beginnen met IPv6 kunnen wij in de toekomst onze dienstverlening blijven garanderen.

De kosten

Dat een implementatie van IPv6 geld kost, is natuurlijk een feit. Maar door langer te wachten met IPv6 zullen de kosten alleen maar toenemen. Het begint al met het bestellen van alle nieuwe apparatuur. Als deze niet IPv6 ready zijn zul je dus later nieuwe apparatuur moeten kopen of iets aanschaffen om er tussen te zetten. Hoe je dit ook bekijkt, het kost geld. Daarnaast loop je het risico een spoed implementatie te moeten doen. In dat geval zul je dus externe consultants en techneuten moeten inhuren om het werk te doen. Door NU te beginnen kun je hierop besparen.

Conclusie

Het overtuigen van nummer 1 en 2 zul je niet kunnen doen met technische argumenten. Door goed te onderzoeken waar hun focus ligt en van daaruit de discussie te starten kun je ze aan jou kant krijgen. Ik hoop dat deze blog elke IPv6 liefhebber helpt om zijn collega’s te gaan overtuigen.

Reacties (5)

Threat Management Gateway 2010: Network Inspection System

Martijn Bellaard — Sun, 18 Apr 2010 19:15:01 +0200

Internet is een steeds gevaarlijkere plaats aan het worden. Moest je vroeger vooral opletten dat je niet iets “fouts” downloadde is dat vandaag de dag anders. Het klikken op een verkeerde link, of spontaan op springende popup’s kunnen er al voor zorgen dat er iets mis gaat. Om gebruikers tegen dit soort bedreigingen te beschermen beschikt de TMG over een Network Inspection System, afgekort NIS. Maar wat is NIS nu precies en hoe werkt het.

Hoe werkt NIS

NIS is een onderdeel van de IPS van de TMG en de werking is vrij simpel. Op het moment dat er een netwerkpakketje binnenkomt op de netwerklaag wordt deze onderschept door NIS. Nadat het onderschept is door NIS wordt er gekeken wat voor application layer protocol het is. Daarna wordt er dieper gekeken in de betreffende protocol , bijvoorbeeld welke extensie er in zit. Op die manier wordt het protocol helemaal uitgepakt. NIS kan de volgende protocollen controleren:

· http

· DNS

· SMB

· SMB2

· NetBIOS

· MSRPC

· SMTP

· POP3

· IMAP

· MIME

GAPA Inspection Engine

Generic Application-level Protocol Analyzer (GAPA) is verantwoordelijk voor het analyseren van de protocol stream. De GAPA maakt gebruik van GAPAL (GAPA Lanquage). Deze taal is ontwikkeld door de Microsoft Research (MSR) om protocollen te kunnen analyseren. De uitkomst van deze analyse wordt vervolgens vergeleken met een database.

De database

De database bestaat uit een aantal signaturen. Deze signature wordt vergeleken met de protocol stream om te bepalen wat voor protocol stream het is. Komt de stream overeen met een signature dan wordt het netwerk verkeer geblokt.

In de database staan drie type signaturen:

Vulnerabiltiy-based: dit type signature zal de verschillende varianten van een exploits voor een specifieke Vulnerabiltiy ontdekken.
Exploid-based: dit type signature geldt voor een speciale exploit.
Policy-based: Als er niet een exploid of Vulnerability-based siganture gemaakt kan worden.

Als beheerder kun je kiezen welke actie je wilt laten uitvoeren voor elke signature. Hierbij kun je kiezen dat als iets voldoet aan de signature om dan te blokkeren of te negeren, het verkeer door te laten dus.

Conclusie

Al het netwerkverkeer dat door de TMG gaat wordt door NIS gecontroleerd. Hierbij wordt er dan gekeken naar netwerk patronen en of deze voldoen aan een speciale signature. Is dit het geval dan zal al het netwerkverkeer geblokt worden.

Natuurlijk kun je er ook voor kiezen NIS uit te zetten, maar daarmee zet je dan ook meteen een mooi stukje beveiliging uit.

Martijn Bellaard

Reacties (1)

Threat Manager Gateway 2010 Workgroup Array

Martijn Bellaard — Mon, 05 Apr 2010 21:08:01 +0200

Het hoger beschikbaar zijn van een ICT omgeving is vandaag de dag steeds belangrijker. Veel IT processen binnen een organisatie zijn bedrijfskritisch geworden en bij uitval van een IT proces liggen belangrijke bedrijfsprocessen snel stil. Veel van deze IT processen maken gebruik van internet en/of zijn bereikbaar vanaf het internet. Hierdoor is de internettoegang ook een IT kritisch onderdeel geworden. De Threat Management Gateway 2010 is verantwoordelijk voor internet toegang en zal dus hoger beschikbaar moeten zijn. Hiervoor moet je als beheerder twee zaken regelen:

- Met Load Balancing zorg je er voor dat al het verkeer over twee of meer TMG’s verdeeld worden en bij uitval van één TMG zullen de overige TMG’s het overnemen

- Met een Array zorg je er voor dat de configuratie over alle TMG’s hetzelfde is.

Met de Threat Management Gateway 2010 (TMG) kun je een workgroup array maken. Deze setup is vooral interessant als de TMG in een DMZ staat en niet lid is van een Active Directory. In deze blog zal ik ingaan op de stappen die je moet zetten om een TMG workgroup Array te maken.

Stap 1) Configuratie ontwerp

Voordat je begint met de setup van de array zul je eerste moeten nadenken over je array storage server. Je hebt hierbij de volgende twee keuzes:

1. Een Dedicated array storage server, in dit geval zal een TMG server als Dedicated array Storage server dienst doen.

2. Een member storage array server, in dit geval zal één van de TMGs ook storage server zijn

In mijn blog ga ik uit van nummer 2. Wil je aan de slag met nummer 1 dan kun je dezelfde setup uitvoeren, maar de Dedicated server mag dan geen onderdeel zijn van de Load Balancing.

Stap 2) Importeer SSL Certificaat

De Threat Management Gateway 2010 slaat zijn informatie op in een instance van de Active Directory Ligthweight Directory Service. Deze vind je terug als de service ISASTGCTRL. In een Array zal alle configuratie informatie opgeslagen worden in de storage array server ISASTGCTRL services. Elk array member zal op basis van SSL een connectie maken met de storage server. Voordat we kunnen beginnen zullen we eerst een SSL certificaat moeten aanmaken voor TMG02.Array.local, TMG01.Array.local. Ik ga, bij de start ervan uit dat we beschikken over de prived key van het certificaat. Deze prived key moet vervolgens worden geïmporteerd en worden gekoppeld aan de ISASTGCTRL service.

De volgende actie moet op beide servers worden uitgevoerd.

- Start è Run è MMC

- File è Add or Remove Snap-ins

- Certificates

- Add

- Service Account

- Next

- Selecteer ISASTGCTRL

- Finish

Je hebt nu de certificaten store geopend van de service ISASTGCTRL.

- OK

- Open Certificates\ADAM_ISASTGCTRL\Personal

- Importeer de prived key.

- Sluit het MMC console

- Restart de service ISASTGCTRL : net stop ISASTGCTRL && net start ISASTGCTRL

!!LET OP!! Er mag maar één certificaat staan in de store. De service kiest automatisch een certificaat om te gebruiken voor SSL.

Stap 3) Aanmaken ARRAY op de TMG02

Nu de service ISASTGCTRL klaar is kunnen we de array gaan definiëren. Dit doen we op de TMG die we gaan gebruiken als storage server. In deze blog is dat TMG02.

Als eerste moet je er voor zorgen dat alle TMGs in de Managed Server Computers- en Remote Management Computers set terecht komen. In de system policy’s staan een aantal policy’s die er dan voor zorgen dat deze computer toegang krijgt tot de ISASTGCTRL services.

- Log aan op de TMG02

- Start de TMG Management console

- Selecteer: Firewall Policy

- Aan de rechterkant selecteer je: Toolbox

- Selecteer :Computer Sets è Managed Server Computers

- Rechtermuisknop è Properties

- Voeg de TMG01.array.local toe

!! LET OP, de FQD moet wel geresolved kunnen worden naar een IP nummer !!!

- OK.

- Apply

- Voeg de TMG02.array.local toe

- OK.

- Apply

- OK

- Apply

- Herhaal deze stappen ook voor de groep Remote Management Computers

We gaan nu het Array definiëren

- Selecteer aan de linkerkant Forefront TMG (TMG02)

- Onder task Configure Array Properties

- Geef als DNS naam TMG02.array.local

- OK

Stap 4) TMG01 toevoegen aan de ARRAY

Nu het array gedefinieerd is kunnen we de andere TMGs gaan toevoegen. Als eerste controleren we of we een connectie kunnen maken met de ISASTGCTRL service over secure LDAP poort 2172

- Log aan op de TMG01

- Start een CMD

- Run LDP.EXE

- Connection

- Connect

o Connect nu naar TMG02.array.local over poort 2172 en selecteer SSL

- OK

- Je moet een lap tekst krijgen die begint met Dn: (RootDSE).

- Connection è Bind è OK

- Je moet de volgende output krijgen:

--------

53 = ldap_set_option(ld, LDAP_OPT_EBCRYPT, 1)

Res= ldap_bind_s(ld, NULL, &NtAuthIdentiy, NEGOTIATE(1158)); // v .3

{NtAuthIdentity: User=’Null’; Pwd=; domain =’NULL’}

Authenticated as: ‘TMG02\Administrator’.

--------

Als je geen foutmeldingen krijgt kan de TMG01 een connectie maken met TMG02\ISASTGCTRL service.

- Start de TMG Management console

- Selecteer aan de linkerkant Forefront TMG (TMG01)

- Onder task Join Array

- Next

- Selecteer Join a standalone array managed by a designated array member (array manager)

- Next

- Array manager IP address of FQDN: TMG02.Array.local

- Next

- Selecteer: The root CA certificate is already installed on this server

- Next

- Finish

Dit duurt een tijd. Heb je een RDP connectie naar de TMG, dan zal deze worden verbroken

- OK

Stap 5) Aanmaken Array Account

Als laatste moet je nu een array account definiëren. Dit account wordt door de array members gebruikt om aan te loggen op het array.

- Maak op beide servers het account : User: TMGArry, Pass: *****************

- Open het TMG console

- Selecteer in de TMG console Forefront TMG (TMG)

- Selecteer rechts Configure Array Properties

- Selecteer Intra-Array Credentials

- Set ...

Reacties (1)

Deel III. Direct Access server setup

Martijn Bellaard — Mon, 08 Mar 2010 09:15:01 +0100

De Direct Access server is een server met twee netwerkkaarten. Eentje gekoppeld aan je LAN, de ander gekoppeld aan het internet. De internetkaart moet minimaal 2 Global IPv4 nummers hebben. Deze twee nummers heeft hij nodig voor Teredo. Installeer op de Direct Access server Windows 2008 R2. Na de installatie maak je hem lid van je Active Directory.

NGN Evenement

"Windows 7; uitdagingen en kansen
van de nieuwe werkplek." op 15 april
Je kan je hier inschrijven

Martijn Bellaard presenteert daar
ook en behandelt oa Direct Access,
bitlocker en IPv6

Leden slechts €50,-
Niet-leden €99,-
Lid worden kan hier

Direct Access feature toevoegen.

Nu de server lid is van het AD kun je de Direct Access feature installeren en RRAS voor NAT funcinaliteit. Dit kun je doen via powershell:

Add-WindowsFeature –IncludeAllSubFeature -Name NPAS-Routing,DAMC

IPv6 config.

DirectAccess werkt op basis van IPv6 en je zult dus IPv6 moeten gaan configureren. Hiervoor kun je gebruik maken van de range FC00:1234:ABCD::/48

Intern NIC DirectAccess server

IPv6 Nummer: FC00:1234:ABCD:0001::2/64
DNS: FC00:1234:ABCD:0001::1

NIC DC

IPv6 Nummer: FC00:1234:ABCD:0001::1/64
Gateway: FC00:1234:ABCD:0001::2/64
DNS: FC00:1234:ABCD:0001::1

Configuratie NAT

De DA server gaat een dubbele rol vervullen. In de eerste plaats is het aan de NAT server om het interne netwerk te scheiden van het externe netwerk. Daarnaast zal hij dienst doen als DirectAccess server.

Optioneel zou je er voor kunnen kiezen om de DA server ook te gebruiken om de CRL lijst te publiceren.

Er komen dus twee netwerkkaarten in. De kaart voor het interne netwerk heeft een intern IP nummer nodig en de kaart voor het externe netwerk heeft twee externe IP nummers nodig.

Enable NAT

Open het RRAS console. Deze staat onder de administration tools
Selecteer Routing and Remote Access
Rechtermuis => Configure and Enable Routing and Remote Access
Next
Selecteer Network address translation (NAT)
Next
Selecteer je extern netwerkkaart
Next
Finish

Configure DirectAccess

De laatste stap is het configureren van DirectAccess. Hiervoor open je de DirectAccess console:

Start
Administrative Tools
DirectAccess Manager

Je hebt nu de DirectAccess Manager console voor je. Hier zie je twee opties Setup en Monitoring, selecteer Setup

Step 1, Remote Clients

Op de DirectAccess Client Setup druk op Add, DA_Client (deze groep hebben we in een eerder blog aangemaakt.)
Finish

Step 2, DirectAccess Server

Op de DirectAccess Server Setup controleer je of de juiste internet interface en internal network interface zijn gekozen.

Nu wordt er een voorstel gedaan voor de IPv6 Prefix. Controleer deze

Next
Klik op de bovenste browse knop en selecteer het certificaat van je eigen CA
Klik op de onderste browse knop en selecteer het certificaat die je in de vorig blog hebt aangevraagd. Dit is een IP-HTTPS SSL certificaat.
Finish

Step 3, Infrastructuur Servers

De Network Location server is een server die de client, op basis van een HTTPS verbinding probeert te benaderen. Lukt dit dan is hij op het interne netwerk zal geen DirectAccess gaan gebruiken. Lukt dit niet dan is hij buiten en zal DirectAccess gaan gebruiken. Kies dus voor een URL die alleen intern te benaderen is.

Vul in: Https://www.interneserver.local
Validate
Los eventuele foute meldingen op. Next
Default waardes zijn voor nu goed genoeg, next
Vul als prefix de IPv6 prefix FC00:1234:ABCD::/48, Finish

Step 4, Application Servers

Deze stap heeft alleen zin als je gebruik maakt van IPSec op je interne netwerk. Tot nu toe in deze blog serie heb ik dat niet gedaan, dus sla ik deze stap over. Wil je wel end-to-end IPSec connectie zul je IPSec moeten configureren op je interne LAN.

Druk nu op Save
Finish
Apply

Nadat je op Apply hebt gedrukt worden de benodigde GPO aangemaakt binnen je Active Directory. Nu kun je een Windows 7 Client lid maken van je domain en de DA_Client groep. Nadat hij de GPO heeft ontvangen zal hij een DirectAccess Connectie opzetten naar de DirectAccess server.

Voor zover de setup van Direct Access. In een volgende blog zal ik wat troubleshooting tips gegeven voor DirectAccess.

Martijn Bellaard

Reacties (1)