#
|
title + summary
|
supervisor contact
students
|
R
P
|
1
/
2
|
7
|
HPC parallel file system.De
afdeling High Performance Computing (HPC) verzorgt onder andere het
beheer van een PC cluster. Op dit Linux cluster is het wenselijk een
parallel filesysteem te implementeren. Voor het Linux operating systeem
zijn een aantal parallelle filesystemen beschikbaar; wij willen echter
de keuze beperken tot PVFS en GFS. Het doel van de opdracht is om een
advies uit te brengen aangaande deze twee filesystemen.
Werkzaamheden: De student installeert en evalueert (door
middel van benchmarking) de parallelle filesystemen PVFS en GFS op
testnodes. De student produceert een rapport waarin zijn/haar
bevindingen beschreven staan en adviseert welk filesysteem we moeten
gaan implementeren op de productiecluster.
|
Huub Stoffers <hs=>sara.nl>
Ans Sullot <Ans=>sara.nl>
Fangbin Liu
<fliu=>science.uva.nl>
|
R
P
|
1
|
11
|
Intrusion Detection System.Ten aanzien van het SURFnet IDS project (http://ids.surfnet.nl) de volgende onderwerpen:
- onderzoek naar veiligheid c.q. beveiliging van de SURFnet IDS dienst
|
Rogier Spoor <rogier.spoor=>SURFnet.nl>
Lourens Bordewijk <lbordewijk=>os3.nl>
Jimmy mace <mace=>os3.nl>
|
R
P
|
1
|
12
|
Passieve DNS replicatie.Onderzoeken hoe passive dns replicatie ingezet kan worden bij SURFnet
|
Rogier Spoor <rogier.spoor=>SURFnet.nl>
Wim Biemolt <Wim.Biemolt=>surfnet.nl>
Dirk-Jan van Helmond <dirkjan=>os3.nl>
Antoine Schonewille
<talitwan=>os3.nl>
|
R
P
|
1
|
19
|
Virtualisatie en distributie.Onderzoek
naar de mogelijkheden, de toepassing en het gebruik van
virtualisatietechnieken met behulp van VMware VirtualCenter en P2V
Assistant. Het onderzoek vindt plaats in een professionele omgeving
waar reeds gebruik gemaakt wordt van virtuele machines op basis van
VMware. Het doel van dit onderzoek is tweeledig:
- Virtualisatie van een fysieke omgeving naar een virtuele omgeving met behoud van alle applicaties en instellingen
- Distributie van meerdere virtuele servers over een infrastructuur bestaande uit meerdere VMware servers
Het resultaat van dit onderzoek zal bestaan uit een
werkend proof-of-concept. De focus zal liggen op de inzetbaarheid,
bruikbaarheid, stabiliteit, schaalbaarheid en performance van de
technologieen. Het project zal uitgevoerd worden bij ASP4all B.V. te
Huizen
|
Martin Maas <mmaas=>asp4all.nl>
Richard de Jong <rjong=>os3.nl>
Bas Eenink <bas=>os3.nl>
|
R
P
|
1
|
22
|
Beveiliging grote overheids organisatie: CERT procedures.Bij de organisatie is een Computer Emergency Team, CERT, ingericht verspreid over de organisatie. Vragen:
- Is de setup conform best practices?
- Hoe kan een CERT het beste worden uitgetest?
|
Ir. E.J. Kuiper
Gert Bon <gbon=>os3.nl>
Jimmy Mace <mace=>os3.nl>
|
R
P
|
2
|
| 24 |
Beveiliging grote overheids organisatie: Vertrouwd Toegangspad.Voor
het genuanceerd toegang bieden tot systemen en applicaties is het
concept Vertrouwd Toegangspad ontwikkeld als modern alternatief voor een
Logisch Gesloten Technische Infrastructuur.
Vragen:
- Is dit concept marktconform?
- Is dit concept haalbaar?
|
Ir. E.J. Kuiper
Steffen van Loon <steffen=>os3.nl>
Fangbin Liu
<fliu=>science.uva.nl>
|
R
P
|
2
|
| 27 |
Covert channels.Hoe kan
informatie ongezien naar buiten worden gesmokkeld op
(bedrijfs)netwerken? Denk aan het gebruik maken van mogelijke don't care
bits in IP headers, het vullen van payload met interessante gegevens
(b.v. het versturen van als vol gemarkeerde ICMP record route pakketten
met hele andere data in de payload) en misbruik op applicatieniveau
(HTTP GET met daar achteraan 'secret' data). Na inventarisatie van
bestaande idee�n en PoC's (tunneling over DNS etc.) en het uitwerken van
nieuwe idee�n kan er ge�xperimenteerd worden met eigen PoC's. Er kan
ook nagedacht worden over mechanismen om mogelijk al bestaande dan wel
ontwikkelde testimplementaties te detecteren: wellicht maakt de
blackhat-community al grootschalig gebruik van geheime kanalen. Het
beoogde resultaat is een rapport met een beschrijving van
(on)mogelijkheden om het e.e.a. praktisch uit te voeren en mogelijke
kanalen te detecteren. Wij zullen Mark en Matthijs voor kerst het e.e.a.
aan relevante informatie doen toekomen om zo te zorgen voor een solide
basis.
|
Eric Nieuwland <Nieuwland.Eric=>kpmg.nl>
Matthijs Koot <mrkoot=>os3.nl>
Marc Smeets <msmeets=>os3.nl>
|
R
P
|
1
|
28
|
De theorie achter en de eigenschappen van praktisch veel toegepaste versleutelalgoritmes voor wachtwoorden.Denk
hierbij b.v. de verschillende mechanismen zoals beschikbaar in Windows,
Oracle, MSSQL en Cisco apparatuur (mits van toepassing: ook WPA PSK).
Wat zijn de gebruikte karaktersets? Welke theoretische grootte heeft de
keyspace (karakterset ^ N * beperkingen)? Welke praktische grootte (denk
b.v. aan keiharde limieten inherent aan het gebruik van bepaalde
opslagmechanismen en gebruikte algoritmen)? Hoe ziet een
voorbeeldberekening er uit? Hoe zit het met portability (geen/account
specifieke/machine specifieke salting) tussen gelijksoortige systemen en
wat zijn dan de gevolgen voor de toepasbaarheid van rainbow tables?
Hoeveel crypts/seconde kunnen er worden berekend (en afgeleid daarvan:
welke lengte kun je in een dag berekenen, hoe lang heb je ongeveer nodig
voor 4/6/8/10 karakters)? Wat zal de toekomst brengen (Moore's law,
inpact van 64-bits hardware voor b.v. DES gebaseerde hashing, etc.)? Het
beoogde resultaat is een rapport waarmee het risico van gebruikte
mechanismen ingeschat kan worden. Welke wachtwoordlengte is benodigd om
'veilig' te zijn tegen blackhats voor een specifieke toepassing voor nu
en in de toekomst? Tevens kunnen er n.a.v. de gemaakte
voorbeeldberekeningen bijvoorbeeld PoC plugins geschreven worden om
rainbow tables te genereren voor algoritmes welke hiervoor geschikt
zijn. Wij zullen Steffen en Gert voor de kerst een voorbeeld m.b.t.
Oracle en andere interessante documentatie doen toekomen om houvast te
hebben.
|
Jeroen van Beek <vanBeek.Jeroen=>kpmg.nl>
Steffen van Loon <steffen=>os3.nl>
Gert Bon <gbon=>os3.nl>
|
R
P
|
1
|
| 29 |
SURFnet IDS.Ten aanzien van het SURFnet IDS project (http://ids.surfnet.nl) de volgende onderwerp:
Het begin van het onderzoek wordt de honeypot Nepenthes
bekeken. Het onderzoek zal zich richten op de werking van Nepenthes in
het vangen van malware. Aan de hand van de binnengekomen meldingen van
Nepenthes zal bekeken worden of er nog malware tussendoor glipt zonder
dat Nepenthes hier iets mee doet.
Als dit onderdeel is afgerond wordt gekeken naar het eventuele
gebruik van andere honeypots (bv. mwcollect, qdetect, honeyd) en tools
voor het IDS. Er worden in ieder geval een aantal andere honeypots
onderzocht en eventueel getest. Van sommige honeypots is namelijk bekend
dat de ontwikkeling stil staat. Binnen SURFNet is een aantal maanden
terug gekozen voor Nepenthes, maar daarna is niet meer gekeken naar
andere honeypots. Als er honeypots en tools zijn welke een meerwaarde
bieden voor het huidige IDS dan wordt bekeken hoe deze kunnen worden
opgenomen binnen het IDS.
Als de tijd het toe laat wordt ook nog gekeken naar TCP
fingerprinting en naar een full interactive honeypot. Nepenthes is high
interactive honeypot en een andere type honeypot is de full interactive
honeypot. De honeypot laat de malware zijn gang gaan en als de malware
klaar is wordt het systeem afgesloten om de schade te analyseren De
sensoren binnen het IDS zijn gebaseerd op Knoppix. Het zou verdacht zijn
als malware een TCP fingerprint doet en terugkrijgt dat het een Knoppix
systeem is terwijl de malware net een aanval heeft gedaan op een lek in
Microsoft Windows.
|
Rogier Spoor <rogier.spoor=>SURFnet.nl>
Mark Meijerink
<mark=>os3.nl>
Jonel Spellen
<jspellen=>os3.nl>
|
R
P
|
1
|
31
|
Ictivity VoIP ConsultancyIctivity
heeft een bepaalde klantomgeving, bestaande uit twee locaties, te weten
Amsterdam en Eindhoven, waar VoIP moet worden uitgerold. De klant heeft
Ictivity de opdracht gegeven om te kijken wat de mogelijkheden hiervoor
zijn. Als eerste zal dan ook een onderzoek moeten worden verricht naar
de mogelijkheden van VoIP en de functie-eisen van de klant. Dit
onderzoek zal bestaan uit verschillende fases.
Om te beginnen zal een plan van aanpak moeten worden opgesteld
om een correcte planning te maken. Daarna zal een inventarisatie van de
huidige netwerk van de klant worden uitgevoerd, hierbij moet gedacht
worden aan een gedetailleerd overzicht van de aanwezige
netwerkcomponenten, hun eigenschappen en hun huidige werkzaamheden.
Verder wordt gekeken naar de aanwezige verbindingen tussen de locaties
en bijvoorbeeld het aantal patchpunten. Vervolgens zullen de behoeftes
van de klant in kaart worden gebracht, zodat de nieuwe omgeving hierop
volledig kan worden afgesteld. Dit zal een duidelijk beeld moeten vormen
over de functionele eisen van het de klant. Met deze eisen kan een
functioneel ontwerp worden opgezet met daarin een gedetailleerd
overzicht van de aanwezige en gewenste functies en diensten, te denken
aan backup, huntgroepen, voicemail, beveiliging etc. Met behulp van dit
functioneel ontwerp, en de informatie van de aanwezige componenten en
diensten, kan vervolgens een technisch ontwerp worden opgezet, met
daarin een overzicht van de vereiste apparatuur, eventuele aanpassingen
aan het huidige netwerk, en nieuwe technieken die moeten worden ingepast
in het bestaande netwerk. Uiteindelijk zal dit onderzoek een
consultancy rapport moeten opleveren met een maatwerk oplossing voor
VoIP voor deze klant. Hierbij speelt ook een kosteneconomisch overzicht
ook een belangrijke rol en zal het consultancy rapport ook moeten worden
gepresenteerd.
Belangrijke punten binnen de onderzoeksopdracht zijn dan ook:
planning, inventarisatie, (functionele) klantbehoeftes, functionele en
technisch ontwerp, budgettaire mogelijkheden en rapportage en
presentatie.
|
Ewout van Dijck <ewout.van.dijck=>ictivity.nl>
Rens Jorissen <rjorissen=>os3.nl>
Rob Prickaerts
<rprickaerts=>os3.nl>
|
R
P
|
1
|
33
|
"Cut Through Switching/routing" op een Internet Exchange.Het
idee van "cut through routing/switch" is dat een deel van het verkeer
in een netwerk niet volgens de normale paden gerouteerd of ge-switched
wordt, maar dat hiervoor een pad tussen twee punten in het netwerk wordt
gecre�erd buiten de "normale" infrastructuur om. Dit kan interessant
zijn om capaciteit beter te verdelen of de performance tussen twee
punten in het netwerk te optimaliseren.
Voorbeeld: Het AMS-IX netwerk is gebouwd volgens een zognaamd
HUB/Spoke model. Dit betekend dat klanten aansluiten op een zogenaamde
edge switch. Deze edge switches zijn niet direct met elkaar verbonden,
maar verkeer tussen edge switches wordt gerouteerd (op laag 2, Ethernet)
via een zogenaamde core switch (de hub). Er zijn in totaal 9 van deze
edge switches. Voor sommige verkeersstromen tussen twee edge switches
kan het mogelijk interessant zijn om die niet via e core switch te
routeren maar een (tijdelijke) directe koppeling te maken tussen twee
edge switches.
Een dergelijk "cut through" pad wordt natuurlijk alleen maar
gemaakt indien voldaan wordt aan een aantal criteria. Men kan hierbij
denken aan een minimale hoeveelheid verkeer tussen twee eindpunten
waarbij de verwachting is dat die verkeersstroom een vooraf
gedefinieerde minimale tijd blijft bestaan.
Het zou interessant zijn om te onderzoeken of een dergelijk
aanpak zinvol is binnen een Ethernet platform als AMS-IX. Zaken die te
onderzoeken zijn:
1: Wat voor gegevens heeft men nodig om een beslissing te nemen een "cut through" pad te cre�ren.
2: Een outline voor de benodigde hard en software om iets
dergelijk te realiseren. Ik kan me voorstellen dat men een server heeft
met analyse software die vervolgens een photonic switch aanstuurt om een
fiber pad te cre�ren tussen twee interfaces op twee switches.
3: Wat zijn de specifieke consequenties van een dergelijk
aanpak voor een Ethernet platform. Zonder meer zullen "cut through"
paden loops in de Ethernet infrastructuur cre�ren. Hoe hier mee om te
gaan ? "Cut through" paden maken we dedicated voor een bepaalde
datastroom, maar zonder maatregelen zal de switch daar adressen over
gaan leren en ongecontroleerd verkeer over sturen, hoe hier mee om te
gaan ? Unidirectional paden? Andere oplossingen ?
|
Henk Steenman <henk.steenman=>ams-ix.net>
Rene Jorissen <rjorissen=>os3.nl>
Lourens Bordewijk <lbordewijk=>os3.nl>
|
R
P
|
2
|
35
|
Integration of MPI support in a large-scale grid deployment.More
and more, tightly-coupled parallel applications that used to run only
on supercomputers are being ported to use the Message Passing Interface
(MPI) library to be subsequently run on (Linux) cluster architectures.
And as these clusters in the scientific domain are increasing couples
together in grids, use of MPI via grid interfaces should to be
supported. To date, only small-scale test beds have made such MPI job
submission possible (both within a single cluster as well as across
different sites), but this is not a feature of the production grids such
as the LHC Computing Grid and the EGEE Infrastructure.
In this project, you will investigate the requirements for
automatic large-scale deployment of MPI on a global scale in the
operational grid infrastucture, build and configure the MPI libraries
for the grid nvironment to be distributed via APT, and integrate this in
the automatic installation and configuration tools ("YAIM") for the LCG
and EGEE grid.
The specific aim is to demonstrate actual integration of MPI
support in the production grid, and prove that MPI job submission to
newly installed sites is successful. You will report on the
extensibility of the YAIM architecure, the scaling and dependency
aspects of the MPI library with respect to the current grid middleware,
and the specific modifications of the grid middleware to support MPI.
|
David Groep <davidg=>science.uva.nl>
Jeff Templon <templon=>nikhef.nl>
Louis Poncet <Louis.Poncet=>cern.ch>
Richard de Jong <rjong=>os3.nl>
Matthijs Koot <mrkoot=>os3.nl>
|
R
P
|
2
|
36
|
Voice over IP.Het doel
van dit onderzoek is om voor het bedrijf Mediparc een zo volledig
mogelijk advies te formuleren met betrekking tot de implementatie,
risico's en alternatieven van Voice over IP. De bedoeling is om
enerzijds een prognose te geven over de toekomst van het breed ge
??mplementeerde Session Initiation Protocol (SIP) en anderzijds de
kwaliteit, schaalbaarheid en risico?s in kaart te brengen van een
implementatie van Voice over IP.
Tevens zal er onderzoek plaatsvinden naar alternatieven voor
VoIP bij uitval. De achterliggende gedachte is dat het landelijke
alarmnummer en politie te allen tijde beschikbaar moet zijn.
De uitvoering van het pro ject zal bestaan uit een
literatuuronderzoek naar relevante artikelen over VoIP en SIP, een
VoIP-testomgeving om onderzoek te doen naar technische aspecten en het
schrijven van een verslag van dit project om de onderzoeksvragen zo goed
en zo objectief mogelijk te kunnen beantwoorden
|
Rob Denekamp <r.denekamp=>mediparc.nl>
Bas Eenink <bas=>os3.nl>
Antoine Schonewille
<talitwan=>os3.nl>
|
R
P
|
2
|
38
|
GMPLS.GMPLS is een
uitbreiding op MPLS en behelst een set van protocollen welke samen
control plane functionaliteiten bieden. Het control plane biedt een
aantal functionaliteiten in een netwerk, voorbeelden
hiervan zijn:
- signaling
- routing
- link management.
In de IP wereld worden deze functionaliteiten verzorgd door routing protocollen zoals OSPF en ISIS.
Met MPLS kunnen Label Switched Paths door een IP netwerk
gemaakt worden. GMPLS breidt dit uit naar lagere lagen in de OSI stack.
Denk hierbij in het bijzonder aan fiber, DWDM en TDM (SDH/SONET).
Uiteindelijk is het de bedoeling dat een eindgebruiker een verzoek doet
aan het control plane, met als vraag: "geef mij een pad van A naar Z"
deze vraag kan eventueel ook nog extra attributen bevatten zoals, delay,
bandbreedte en explicit route eisen.
De GMPLS protocol suite bestaat op dit moment voornamelijk uit
RSVP-TE signaling) en OSPF-TE (routing). Van beide protocollen zijn
open source implementaties beschikbaar. Deze opdracht omvat het in kaart
brengen van en testen van deze software, met als uiteindelijk doel een
testomgeving te hebben om GMPLS gerelateerde protocollen te testen.
In het lab zal een eenvoudige testopstelling gemaakt worden met enkele hosts en een of meerdere Ethernet switches.
De studenten zullen zodoende een beter inzicht krijgen in hoe
in toekomstige netwerken control plane technologie�n toegepast kunnen
worden en kennis op doen van protocollen uit de GMPLS protocol suite met
als resultaat een goed beeld van wat GMPLS kan bieden en hoe dit de
verschillende protocollen werken en hoe ze zich tot elkaar verhouden.
|
Ronald van der Pol <rvdp=>sara.nl>
Paola Grosso <grosso=>science.uva.nl>
Rob Prickaerts <rprickaerts=>os3.nl>
Mark Meijerink
<mark=>os3.nl>
|
R
P
|
2
|
39
|
Benefits and tradeoffs of application-specific WAN acceleration technologies on different latency and loss scenarios.Growing
bandwidth demand by corporate users has created a market for
application-aware "WAN acceleration platforms", i.e. devices that help
make optimal use of all available bandwidth by eliminating protocol
inefficiencies. The Juniper WX platform helps improve application
performance over WAN links with a number of transport and
application-specific optimisations; the goal of this project is to
evaluate the performance benefits and tradeoffs encountered when
deploying the WX platform over links with
different delay, jitter and loss characteristics.
**Detailed description
The candidates will be expected to:
Familiarize themselves with the WX platform, its features and
configuration. Find a way to simulate links with different
characteristics using the available tools. Develop and execute a test
plan to evaluate WX performance in different scenarios.
**Deliverables
WX configuration and setup.
Application servers configuration and setup.
Test plan and results.
Tools/resources needed:
Juniper will provide a lab setup consisting of the WX-series
hardware, a few servers that can be used to simulate realistic
application load, and the use of the available JTAC traffic generators
and analyzers. In addition to these, the candidates are encouraged to
use any of the freely avaliable network analisys and simulation tools.
|
Saverio Pangoli <spangoli=>juniper.net>
Dirk-Jan van Helmond <dirkjan=>os3.nl>
Marc Smeets <msmeets=>os3.nl>
|
R
P
|
2
|
