Inzichtelijk maken verkeersstromen op netwerk

[Isegrimm]

Hoi,
Ons bedrijf heeft op dit moment ongeveer 40 servers draaien in een datacenter bij een externe partij. Deze externe partij gaat over naar een nieuw virtueel infrastructuurplatform, waarbij men zogenaamde netwerksilo's wil inrichten.
Deze silo's gaan elk een of meerdere servers bevatten en het is de bedoeling dat elk van deze silo's een duidelijk afgebakende applicatie bevat, zoals bijvoorbeeld een mailomgeving waarin de Exchange CAS en Mailbox servers staan.

Nu komt het addertje, deze silo's hebben onderling standaard geen netwerkconnectivity. Alle verkeer wat doorgelaten moet worden, moet worden gedefinieerd in de netwerklaag.
Hiervoor moeten wij dus inventariseren welke verkeersstromen er precies zijn. We hebben alleen toegang tot de VM's via RDP, we hebben geen toegang tot vSphere en de fysieke netwerkcomponenten.

Ik had zelf gedacht om op elke VM een Wireshark capture te laten draaien gedurende een dag of twee/drie om per VM een conversationlist te creëren, maar dit lijkt me geen goeie oplossing, alleen al omdat dit een vrij zware load gaat leggen op de omgeving.
Heeft iemand hier vaker mee te maken gehad en misschien wat tips hoe dit het beste is aan te pakken?

Alvast vriendelijk bedankt

[ZeRoC00L]

Neem aan dat die partij er wel meer ervaring mee heeft omdat ze dit zo willen gaan inrichten ?
Wat zeiden zij toen je het vroeg ?

[Ximon]

Wiresharken en alles definieren wat nu al met elkaar kletst klinkt als de Wet van Behoud van Ellende in effect. De leverancier zal waarschijnlijk redenen hebben waarom ze dit willen doorvoeren, en mijn gevoel zegt dat het hele spul 1 op 1 overzetten haaks op deze redenen staat. Volgens mij kan je beter in je inventaris aan applicaties duiken en definieren wat er allemaal aan communicatie nodig moet zijn. De rest is grondig testwerk

[Question Mark]

Isegrimm schreef op woensdag 15 april 2015 @ 11:54:
Heeft iemand hier vaker mee te maken gehad en misschien wat tips hoe dit het beste is aan te pakken?

Leuk bedacht van die partij, maar aangezien praktisch elke applicatieserver verbinding heeft met het domein, en domaincontrollers onderling ook verbinding hebben gaat dit geen succes worden.

Laat hun maar met een voorstel komen. Zij willen iets veranderen, niet jij.

[CAPSLOCK2000]

Sniffen is een oplossing maar daar zou ik niet mee beginnen. Je kan beter high-level beginnen en verkeersttromen die je verwacht benoemen. Daarna kan je sniffen op wat over blijft om te kijken of je iets mist.

Als het goed is weet je welke applicaties je draait en aan de hand daarvan kun je bepalen welke stromen er moeten zijn. Als je dat niet weet kun je nog kijken naar de firewalls. Dan weet je welke ip-adressen en poorten met elkaar mogen praten. Als je zelfs geen firewall hebt (ga dat eerst oplossen) dan kun je nog kijken naar welke poorten er geopend zijn door applicaties.

Zelf zou ik beginnen met alles in één silo te stoppen en daar dan langzaam stukjes uit te trekken. Het beste moment is als je een nieuwe server inricht. Dan kun je die direct in een silo stoppen zodat je zeker weet dat je niks vergeet en je geen bestaande diensten stuk gaat maken. Een ander goed moment is om het met grote upgrades te combineren. Als er nieuwe versie van je OS uit komt ofzo.

[Isegrimm]

Waarschijnlijk is het inderdaad het beste om de applicaties te inventariseren voorzover er documentatie over is. De rest van het verkeer wordt mogelijk inzichtelijk als er firewall logs bekeken gaan worden. Hier hebben we helaas geen toegang toe dus hiervoor zullen we wel afhankelijk zijn van hun.
Wel hebben ze al toegezegd gedurende de overgangsfase niet al te strict het silo-concept na te zullen leven, dus het is in eerste instantie wel mogelijk om een trosje servers in 1 silo te hangen en deze later los te trekken naar hun eigen silo.
Overigens denk ik dat er bij hun zelf wel meer docu is over de verkeersstromen op hun eigen systemen. Daar schort het bij ons wel redelijk aan moet ik eerlijk zeggen, maar er is vanuit ons nooit rekening gehouden met een dergelijk concept. Daarnaast komt ons bedrijf uit een doorstart waarbij er veel mensen en bijbehorende kennis zijn verdwenen, dat maakt het nog een stukje uitdagender

[CAPSLOCK2000]

Grijp de kans aan om het nu wel de documenteren.

[Jazzy]

Isegrimm schreef op woensdag 15 april 2015 @ 11:54:
Deze silo's gaan elk een of meerdere servers bevatten en het is de bedoeling dat elk van deze silo's een duidelijk afgebakende applicatie bevat, zoals bijvoorbeeld een mailomgeving waarin de Exchange CAS en Mailbox servers staan.

Nu is dit een slecht voorbeeld want die twee rollen heb je volgens Microsoft best practice op één server geïnstalleerd. Maar Exchange is ook een voorbeeld van een applicatie waar geen firewall tussen de servers onderling en tussen servers en domain controllers mag zitten die ook maar iets doet met het verkeer. Wat dat betreft wordt dat dus al een ANY-ANY rule voor die servers.

Verder denk ik dat dit plan op papier misschien heel goed leek, maar in de praktijk een enorm risico omvat. Namelijk dat je iets over het hoofd ziet, dat een update het gedrag van de applicatie verandert of dat er esentieel verkeer is wat net even niet plaats vond toen jij aan het meten was. Bovendien is van veel applicaties geen goede documentatie beschikbaar om uit te vogelen welke verkeersstromen er spelen. Het risico is dus dat dit proces dingen stuk gaat maken en het troubleshooten enorm complex maakt. Kortom, niet iets wat je moet willen. Tijd voor een andere partij of een betere oplossing voor jullie omgeving.

[Question Mark]

Wat wil men overigens bereiken? Is dit vanwege security (waarbij ik twijfel of de winst opweegt tegen de risico/impact/kosten), of wil men dit om andere redenen doen? (bv. minder bendoigde bandbreedte tussen virtualisatiesilo's).

Is er ook uitgelegd waar voor jullie de winst in zit?

[knutsel smurf]

Kijk eens naar de alcatel-lucent enterprise os6860e die heeft VM snooping en volledige DPI mogelijkheden. Door van deze switch gebruik te maken kan je alles zien. Mocht je binnen je vxlan verkeer willen kijken wat hier denk ik niet nodig is zal je naar een os6900-q32 of een os6900-x 72 moeten.

Als je meer dan 4 poorten op 10gbe nodig hebt moet je zowiesoo naar de 9600 modellen toe

[Gomez12]

A : Laat de partij uitleggen wat de voordelen zijn...
B : Documenteer het eens van 2 moeilijke servers
C : Maak een nieuwe VM aan, installeer daar een firewall op
D : Stel op die firewall de regels in van je documentatie uit B + een deny-all
E : Mieter firewall tussen die 2 servers en kijk naar het resultaat.
F : Ga weer met die partij om tafel en vraag waarom ze het willen

Dit is wmb echt iets van meten is weten. Ik ken het tijdspad niet, maar vertrouwen op "tijdelijk" in 1 silo en dan uitbouwen zou ik niet aan beginnen zonder test. Dan verleg je een probleem enkel naar de toekomst waar je nu de impact niet van weet (maar nu is wel het beslissingsmoment)

[jimbo123]

Ben het met Jazzy eens, tijd voor een andere partij.
Je wil gewoon any/any tussen je normale servers.

[CyBeR]

jimbo123 schreef op donderdag 16 april 2015 @ 11:11:
Ben het met Jazzy eens, tijd voor een andere partij.
Je wil gewoon any/any tussen je normale servers.

Of je dat wilt is iets anders maar je wilt er iig zelf de zeggenschap over hebben.

[Isegrimm]

Over de partij hebben we geen zeggenschap, ons moederbedrijf werkt hiermee samen.
Maar ik had wel al eerder gehoord her en der dat dit een beetje de trend aan het worden is, om groepen servers qua netwerk in gescheiden containers/silo's te zetten. Mede vanwege security, maar ook om een duidelijke scheiding te krijgen tussen de verschillende omgevingen.
Is dat niet zo? Het is de eerste keer dat ik er in de praktijk mee te maken krijg, dus noem mij maar een noob op dit gebied

[Jazzy]

Het is prima als een service provider jullie omgeving in een aparte silo plaatst en die van een andere klant in een andere silo, dat is inderdaad een best practice aan het worden. Maar dat jullie integrale omgeving opgeknipt wordt is iets heel anders.

Maar de vraag is op dit moment hoe groot de silo's kunnen zijn en tot hoever je gedwongen wordt om te compartimenteren. Stel dat je uitkomt op twee silo's, een voor de DMZ en één voor de interne servers, dan is het prima te doen.

[Dennism]

Wat is jullie link met deze partij, verzorgen zij alleen het platform en doen jullie al het andere werk (server beheer, uitrol, applicatie beheer, security e.d.) of is het een partij die "ontzorging" aanbied op het gebied van het ICT beheer, waarbij jullie alleen het applicatie beheer, user management e.d. doen.

In het eerste geval zou ik namelijk verwachten dat een dergerlijk verzoek vanuit de klant moet komen, en niet vanuit de hosting partij.

In het 2de geval zou ik verwachten dat zij alle ins en outs van de infra al kennen op netwerk, server en security gebied, en dit soort zaken dus duidelijk niet bij de klant zouden moeten neerleggen, behalve dan dat de klant op de hoogte is van het plan, en de zekerstelling dat de klant geen hinder gaat ondervinden van de veranderingen naar het nieuwe concept.

Een scheiding tussen de infra van verschillende klanten is inderdaad zeker geen nieuw concept, en zelfs aan te raden op het gebied van security, echter afhankelijk van hoe de aanbieding van het concept van de externe partij is, zou dit zeker geen zaak moeten zijn van de eindklant, tenzij je echt enkel de infra afneemt, en verder geen extra services.

[ Voor 18% gewijzigd door Dennism op 17-04-2015 11:11 ]

[Dafjedavid]

Dit riekt een beetje naar invoering van/migratie naar SDN/ACI

[johnkeates]

Je kan gewoon netstat bijhouden/loggen, dan heb je alle host:port conversaties die je maar wil.

[Bl@ckbird]

Dafjedavid schreef op zondag 19 april 2015 @ 14:11:
Dit riekt een beetje naar invoering van/migratie naar SDN/ACI

Daar heeft het idd. veel van weg. Bij ACI staat alles standaard dicht en verkeer moet je expliciet toestaan. Op termijn komen er Application Profiles voor veel gebruikte applicaties, zoals Exchange en SAP. Maar dit modelleren is nu nog gewoon handwerk. IMHO dient de hosting partij een expert te regelen, die jullie kan helpen met het modelleren van jullie applicaties. Jullie hosting partij heeft ook toegang tot het achterliggende netwerk.

[Isegrimm]

Jazzy schreef op vrijdag 17 april 2015 @ 10:19:
Het is prima als een service provider jullie omgeving in een aparte silo plaatst en die van een andere klant in een andere silo, dat is inderdaad een best practice aan het worden. Maar dat jullie integrale omgeving opgeknipt wordt is iets heel anders.

Maar de vraag is op dit moment hoe groot de silo's kunnen zijn en tot hoever je gedwongen wordt om te compartimenteren. Stel dat je uitkomt op twee silo's, een voor de DMZ en één voor de interne servers, dan is het prima te doen.

Inmiddels is me duidelijk dat het gaat om 1 silo voor ons als klant. Alle servers (DMZ, intern, etc) komen in deze silo en alle verkeer van/naar/tussen deze servers wordt gefirewalled. Toegestaan verkeer moet echt per server worden gedefinieerd. Voor de firewalling gebruiken zij VMware NSX.
Ik denk dat het een keuze is om een datacenter op deze manier te designen, en dat je net zo goed 1 silo per netwerksegment kunt definieren en daarin alle verkeer toestaat. Maar goed, we moeten het ermee doen.

[Isegrimm]

Dennism schreef op vrijdag 17 april 2015 @ 11:07:
Wat is jullie link met deze partij, verzorgen zij alleen het platform en doen jullie al het andere werk (server beheer, uitrol, applicatie beheer, security e.d.) of is het een partij die "ontzorging" aanbied op het gebied van het ICT beheer, waarbij jullie alleen het applicatie beheer, user management e.d. doen.

In het eerste geval zou ik namelijk verwachten dat een dergerlijk verzoek vanuit de klant moet komen, en niet vanuit de hosting partij.

In het 2de geval zou ik verwachten dat zij alle ins en outs van de infra al kennen op netwerk, server en security gebied, en dit soort zaken dus duidelijk niet bij de klant zouden moeten neerleggen, behalve dan dat de klant op de hoogte is van het plan, en de zekerstelling dat de klant geen hinder gaat ondervinden van de veranderingen naar het nieuwe concept.

Een scheiding tussen de infra van verschillende klanten is inderdaad zeker geen nieuw concept, en zelfs aan te raden op het gebied van security, echter afhankelijk van hoe de aanbieding van het concept van de externe partij is, zou dit zeker geen zaak moeten zijn van de eindklant, tenzij je echt enkel de infra afneemt, en verder geen extra services.

De verantwoordelijkheden liggen een beetje in het midden. Er zijn legacy servers (geimporteerd van toen we alles nog wel in beheer hadden) en nieuwe servers die door de hosting partij worden uitgerold volgens vastgestelde templates. Alle servers kunnen wij met rdp benaderen, maar verder hebben we geen toegang tot welke infra resource dan ook (netwerk, storage, virtualisatielaag). Toegang op VMware niveau gaat waarschijnlijk wel mogelijk worden als de migratie naar hun nieuwe platform is afgerond.

[Isegrimm]

Bl@ckbird schreef op zondag 19 april 2015 @ 19:29:
Daar heeft het idd. veel van weg. Bij ACI staat alles standaard dicht en verkeer moet je expliciet toestaan. Op termijn komen er Application Profiles voor veel gebruikte applicaties, zoals Exchange en SAP. Maar dit modelleren is nu nog gewoon handwerk. IMHO dient de hosting partij een expert te regelen, die jullie kan helpen met het modelleren van jullie applicaties. Jullie hosting partij heeft ook toegang tot het achterliggende netwerk.

Ondertussen is me wel duidelijk geworden dat ik min of meer die expert ben, in elk geval met het in kaart brengen van de netwerkstromen
De hosting partij helpt wel op veel fronten en er is sprake van korte lijnen, maar het is inderdaad allemaal handwerk op dit moment.

[CyBeR]

Isegrimm schreef op vrijdag 24 april 2015 @ 10:56:
[...]

Ik denk dat het een keuze is om een datacenter op deze manier te designen, en dat je net zo goed 1 silo per netwerksegment kunt definieren en daarin alle verkeer toestaat. Maar goed, we moeten het ermee doen.

Ik denk dat jij de klant bent en de beheerder van die servers (of niet?) en dat als jij dat op die manier wilt, zij dat hebben te regelen. Toch?

[Isegrimm]

CyBeR schreef op vrijdag 24 april 2015 @ 11:49:
[...]


Ik denk dat jij de klant bent en de beheerder van die servers (of niet?) en dat als jij dat op die manier wilt, zij dat hebben te regelen. Toch?

We hebben helaas niet zoveel te bepalen. We zijn onderdeel (samen met een aantal andere bedrijven) van een moedermaatschappij die deze strategie samen met deze hostingpartner bepaald heeft voor alle dochterondernemingen wereldwijd.
Het is dus een kwestie van uitvoeren wat 'corporate' heeft beslist. Maar op zich lijkt het me ook wel goed voor het opbouwen van m'n kennis en ervaring hiermee, het is alleen wat veel werk

[CyBeR]

Isegrimm schreef op vrijdag 24 april 2015 @ 12:00:
[...]

We hebben helaas niet zoveel te bepalen. We zijn onderdeel (samen met een aantal andere bedrijven) van een moedermaatschappij die deze strategie samen met deze hostingpartner bepaald heeft voor alle dochterondernemingen wereldwijd.
Het is dus een kwestie van uitvoeren wat 'corporate' heeft beslist. Maar op zich lijkt het me ook wel goed voor het opbouwen van m'n kennis en ervaring hiermee, het is alleen wat veel werk

Ah ok, dat verandert de zaak wel enigszins.

[MrBaggins]

Hm, ik lees nergens netflow: brengt de verkeersstromen prima in kaart, Vervolgens documenteer je ze in een matrix. NFSEN of NTOP kunnen dit denk ik prima voor je doen. Aan de management kant van je netwerk zou ik sowieso alles naar een centrale plek sturen waar je een netflow collector en eventueel een sniffer neerhangt, alsmede log analyse software om te weten wat er allemaal gebeurt in je netwerk. Als je nu toch alles opnieuw moet inrichten, zou ik dat meteen meenemen.

[Dafjedavid]

MrBaggins schreef op donderdag 30 april 2015 @ 09:57:
Hm, ik lees nergens netflow: brengt de verkeersstromen prima in kaart, Vervolgens documenteer je ze in een matrix. NFSEN of NTOP kunnen dit denk ik prima voor je doen. Aan de management kant van je netwerk zou ik sowieso alles naar een centrale plek sturen waar je een netflow collector en eventueel een sniffer neerhangt, alsmede log analyse software om te weten wat er allemaal gebeurt in je netwerk. Als je nu toch alles opnieuw moet inrichten, zou ik dat meteen meenemen.

Dat komt denk ik doordat hij al heeft uitgelegd, of ik maak dat op uit het verhaal, servers huurt bij een externe partij. Die willen iets gaan doen met netwerksilo's. Dan trek ik voorzichtig de conclusie dat hij geen toegang heeft tot de netwerkomgeving en daarom ook geen netflow kan inrichten. Kan tegenwoordig ook in VMware of een firewall, maar doe daarbij nu even dezelfde aanname....

[Isegrimm]

Dafjedavid schreef op zaterdag 02 mei 2015 @ 21:52:
[...]


Dat komt denk ik doordat hij al heeft uitgelegd, of ik maak dat op uit het verhaal, servers huurt bij een externe partij. Die willen iets gaan doen met netwerksilo's. Dan trek ik voorzichtig de conclusie dat hij geen toegang heeft tot de netwerkomgeving en daarom ook geen netflow kan inrichten. Kan tegenwoordig ook in VMware of een firewall, maar doe daarbij nu even dezelfde aanname....

Klopt, in zoverre dat ons moederbedrijf met deze partij samenwerkt. We hebben zelf geen zeggenschap of financiële middelen om naar een andere partij over te stappen of het serverpark zelf in beheer te nemen.

We hebben alleen toegang tot de VM's via rdp, ping, smb, etc etc. Als bijvoorbeeld een VM met een bluescreen staat en niet automatisch reboot moeten we hun bellen om de VM te resetten.
Toegang tot andere componenten (switches, routers, firewalls, vSphere) hebben we niet.