Quarantined netwerk advies

[Workaholic]

We werken momenteel veel met vmware om klanten omgevingen te testen.

Dit gaat allemaal op een apart netwerk die fysiek is gescheiden van ons productie netwerk.

Dit test netwerk (Quarantined netwerk) is zo ingesteld dat elke klant een aparte vlan heeft. Elke vlan heeft een vmware server 1.05 staan(fysiek) met daarop de vm's van de klanten (servers + clients).

Dit gaat allemaal perfect met uitzondering dat het lastig is om daadwerkelijk te testen.

Momenteel pakken we een laptop, koppelen deze vast aan het betreffende vlan waar we mee willen werken en maken dan een remote desktop verbinding met de betreffende vmware server.

Mooier zou zijn om vanaf de werkstations in het productie netwerk een koppeling te maken met deze klantenomgevingen zonder hiervoor fysiek met laptops, clients of netwerk kabels te klooien.

Probleem hierbij is natuurlijk dat je hiermee de "scheiding" tussen productie en Quarantined kwijt raakt. Dit wil ik niet, zeker niet vanwege het feit dat er per klanten omgeving vaak een dhcp server actief is, of zelfs identieke server/hostnamen heeft als pc's in ons netwerk.

Heeft iemand een idee hoe ik dit aan kan pakken? Het mag nu dan wel allemaal werken en lekker veilig zijn, probleem blijft dat mensen fysiek weg moeten vanaf hun werkplek en met hardware moeten slepen om te kunnen testen. Dit kost tijd en vooral geld.

Ik zat te denken aan een tweede firewall + terminal server of vpn oplossing die tussen de twee netwerken in staat.

Omdat de klantenomgevingen virtueel zijn en de netwerk instellingen op host only staan (met de vm server) heb ik in principe alleen verkeer tussen de fysieke vmware servers in elk vlan segment en de pc/firewall tussen het productie en Q. netwerk.

Probleem blijft echter dat wanneer de netwerk instellingen niet goed staan op een vmware server/client ik toch het risico heb dat er traffic tussen de klanten omgeving en de terminal server mogelijk is en hiermee een risico heb..

Hoop dat het een beetje duidelijk is en PNS waardig is, ben benieuwd of iemand mij kant vertellen of ik uberhaupt veilig een koppeling kan creeeren tussen deze netwerken..

[Verwijderd]

Hoe benaderen de klanten zelf deze testnetwerken remote? Of doen ze dat niet?

[jvanhambelgium]

Eventueel kijken naar een (SSL) VPN oplossing.
Vanaf productie zet je een VPN op naar de gateway (die tussen prod & test staat)
Als de VPN opgezet is heb je geen verbinding met productie LAN meer (geen split tunneling, tenzij je dat echt wil)

Na het opzetten van de VPN krijg je netje een IP van binnen de testrange en je kan dan beginnen spelen.

Mits een goede config van de firewall/vpn gateway tussen de netwerken zal NIET terugvloeien in de productieLAN.

Wat je WEL niet onder controle hebt is eventuele besmetting van een portable PC tijdens dat die een VPN heeft opstaan met de test-omgeving. Wil je dat verhinderen zal je er eventueel iets "terminal-server-achtig" moeten tussenzetten (steptone) vanwaar je verder kan springen naar de machines van klant X of Y

[Verwijderd]

Daar zat ik ook aan te denken idd vandaar mijn vraag hoe de klanten zelf inbellen

[Brahiewahiewa]

Je zou ook al je vmware servers kunnen voorzien van een extra nic en die laten samen komen op een vlan waarin je terminal server staat. Je zou dan zelfs zonder risico de terminal server van een tweede nic kunnen voorzien die in het productie netwerk zit (ok, met een IP filter op port 3389)

[Bl@ckbird]

jvanhambelgium schreef op vrijdag 08 augustus 2008 @ 10:52:
Wat je WEL niet onder controle hebt is eventuele besmetting van een portable PC tijdens dat die een VPN heeft opstaan met de test-omgeving. Wil je dat verhinderen zal je er eventueel iets "terminal-server-achtig" moeten tussenzetten (steptone) vanwaar je verder kan springen naar de machines van klant X of Y

Als je SSL VPN met een ASA5500 uitrolt kun je gebruik maken van Cisco Secure Desktop (CSD).
Dit is een virtuele sandbox omgeving, zodat de host de server niet besmet. (Andersom (server-->host) werkt natuurlijk ook.) Zorg wel dat je met ASA software 8 of hoger werkt.

Configuratie linkje.

[Virtugon]

Brahiewahiewa schreef op vrijdag 08 augustus 2008 @ 11:53:
Je zou ook al je vmware servers kunnen voorzien van een extra nic en die laten samen komen op een vlan waarin je terminal server staat. Je zou dan zelfs zonder risico de terminal server van een tweede nic kunnen voorzien die in het productie netwerk zit (ok, met een IP filter op port 3389)

Dat lijkt me wel een mooie oplossing maar zou dit niet kunnen zorgen voor contaminatie van dataverkeer tussen de verschillende test netwerken?

Ik zat te denken aan iets als een standaard kleine image van een terminal server die je op elke VMware server kunt zetten als zijnde "access server". Je kunt deze dan een 2e Virtuele NIC geven in een soort van management VLAN (met een aparte IP range uiteraard) en dit VLAN doorpatchen naar vrije patchpunten op de werkplekken van de engineers. Of je kunt de 2e NIC van deze "access servers" in het productienetwerk gooien, maar dat is natuurlijk weer een hoger risico.

[Workaholic]

bedankt voor de feedback totzover.

Gelukkig hoeven de klanten niet bij dit netwerk en of vlans te kunnen dus het is hoofdzakelijk alleen voor onze support/develop medewerkers.

Een cisco setup plaatsen kost wel wat centen, zo'n ASA unit al helemaal.. ik denk dat de ssl/vpn oplossing icm goede firewall rules de beste keuze is. Liefst allemaal opensource om ook nog is de licentie kosten te drukken.

[Workaholic]

Om nog even door te gaan op de reacties en dit onderwerp.

Ik heb het volgende in gedachten en twijfel tussen deze twee?
optie 1

code:

Productie netwerk (Vlan 1 ) ----> Terminal server vlan nic 1 (vlan 1)
                            nic 2 (vlan 2) ---> test netwerk via remote desktop

optie 2

code:

Productie netwerk (Vlan 1 ) ----> vpn verbinding met een firewall in vlan1/2
     VPN dhcp lease in vlan 2 range --> remote desktop sessie vmware server
fw rule --> deny traffic between vlan 2-->1?

Vragen :

- De tweede optie is veel goedkoper omdat er geen terminal server nodig is. De workstations krijgen via een vpn verbinding direct een verbinding met het test netwerk en kunnen dan via remote desktop een verbinding maken met de vmware servers/clients. Met de firewall kan ik tevens de traffic monitoren en blocken waar nodig.

- Ik ben een beetje huiverig voor de dhcp servers en zelfde ip ranges/hostnames in het test netwerk. Hoeveel risico loop ik hiermee ? Is optie 1 in dit geval beter dan 2? of andersom?

- Zijn er nog andere betaalbare oplossingen die beter zijn dan mijn suggesties? Is het verstandig om nog een extra firewall te configen bij optie 1 als ik deze kies? Die ik tussen de terminal server en vlan 1 zet?

[Leon T]

Je maakt het jezelf veel te moeilijk. Zie onderstaand plaatje; sluit je normale vlan aan op de inside interface van een asa 5505 (met security plus, anders heb je niet genoeg vlans). Sluit vervolgens de klant vlans ook aan op je asa, met elk vlan in een aparte interface. Geef deze dezelfde security level en ze kunnen niet onderling communiceren. Afhankelijk van wat je wilt kun je de netwerken van de klant routeren vanaf je eigen netwerk, of je kunt ze doornatten vanaf de inside.
Standaard kan je niks, je moet dus openzetten wat je mag; bijvoorbeeld inside -> any : 3389. Hoef je je ook geen zorgen te maken over DHCP en wat dan ook.

[SpamLame]

Leon T schreef op maandag 11 augustus 2008 @ 18:49:
Je maakt het jezelf veel te moeilijk. Zie onderstaand plaatje; sluit je normale vlan aan op de inside interface van een asa 5505 (met security plus, anders heb je niet genoeg vlans). Sluit vervolgens de klant vlans ook aan op je asa, met elk vlan in een aparte interface. Geef deze dezelfde security level en ze kunnen niet onderling communiceren. Afhankelijk van wat je wilt kun je de netwerken van de klant routeren vanaf je eigen netwerk, of je kunt ze doornatten vanaf de inside.
Standaard kan je niks, je moet dus openzetten wat je mag; bijvoorbeeld inside -> any : 3389. Hoef je je ook geen zorgen te maken over DHCP en wat dan ook.

[afbeelding]

Waarbij je over het hoofd zit dat TS het ook over de centen heeft en met name een ASA config (te?) duur is. TS heeft het liefst een produkt waarbij geen licentie en aanschaf kosten gemoeid zijn (mijn vrije vertaling). Dat de technische oplossing complexer wordt is schijnbaar geen probleem, hoewel daar in termen van beheer en ondersteuning mogelijk hogere kosten aan verbonden zijn.

[Vicarious]

Als je de servers van de klanten in een eigen VLAN zet, niet tussen deze VLANS routeert en geen IP helper adressen instelt is er toch geen onderlinge communicatie mogelijk?

[Workaholic]

SpamLame schreef op donderdag 14 augustus 2008 @ 10:27:
[...]


Waarbij je over het hoofd zit dat TS het ook over de centen heeft en met name een ASA config (te?) duur is. TS heeft het liefst een produkt waarbij geen licentie en aanschaf kosten gemoeid zijn (mijn vrije vertaling). Dat de technische oplossing complexer wordt is schijnbaar geen probleem, hoewel daar in termen van beheer en ondersteuning mogelijk hogere kosten aan verbonden zijn.

Klopt helemaal. We hebben al licenties voor terminal services en een firewall kan via opensource als het nodig is.

In een test netwerk ben ik aan het testen met verschillende mogelijkheden voor dit " probleem" .

Momenteel heb ik de volgende constructie gemaakt :



- Terminal server is " brug " tussen de twee netwerken met behulp van 2 nics (192 range en 10x range)

Verbinding vanaf workstations in het productie netwerk naar test netwerk gaat dan via :

- RDP --> terminal server
- Terminal server sessions --> via nic 2 naar --> 192x ip range --> test netwerk/clients

Hierbij ga ik uit van 1 test vmware server in het test netwerk.

De volgende vragen hierbij (uitgaande van 1 test netwerk/1klant en bovenstaande tekening)

- Is het nog nodig om op de tekening een firewall te plaatsen (simpel unix ding) die overbodig verkeer blokt? Liever te veel security dan te weinig toch? Desnoods alleen 3389 door laten?

- Hoe voorkom ik dat er Broadcast verkeer en dhcp packets vanaf het netwerk via de terminal server niet bij ons productie netwerk komt? Vrees dat ik hier toch een firewall voor nodig ga hebben?

[ Voor 14% gewijzigd door Workaholic op 14-08-2008 16:51 ]

[jvanhambelgium]

>Is het nog nodig om op de tekening een firewall te plaatsen (simpel unix ding) die overbodig verkeer >blokt? Liever te veel security dan te weinig toch? Desnoods alleen 3389 door laten?

Helemaal geen slecht idee...indien de terminal server gecompromiteerd zou worden heb je tenminste nog een stok achter (euh..tussen) de deur.
Je zou kunnen zeggen als policy dat er geen "initierend" verkeer vanaf de terminal server richting productie mag...aangevuld met nog wat ander leuks...


>Hoe voorkom ik dat er Broadcast verkeer en dhcp packets vanaf het netwerk via de terminal server >niet bij ons productie netwerk komt? Vrees dat ik hier toch een firewall voor nodig ga hebben?

Die DHCP broadcast gaat niet door de terminal server heen hoor.
Bezie de TS als een "router" (niet niet route btw) en de DHCP broadcast komt niet verder als de 192.168.23.x NIC.

[SpamLame]

Op de terminal server routing disablen zou afdoende moeten zijn om verkeer tussen de netwerken te voorkomen. Als je daarbovenop ip beveilings beleid (gpedit of een GPO) aansteekt op de TS zodat er ook alleen op de door jou gekozen poorten gecommuniceerd kan worden, dan zou een extra firewall wellicht overbodig zijn.

[Workaholic]

jvanhambelgium schreef op donderdag 14 augustus 2008 @ 18:19:
Helemaal geen slecht idee...indien de terminal server gecompromiteerd zou worden heb je tenminste nog een stok achter (euh..tussen) de deur.
Je zou kunnen zeggen als policy dat er geen "initierend" verkeer vanaf de terminal server richting productie mag...aangevuld met nog wat ander leuks...

Zoiets zat ik inderdaad ook aan te denken, een opensource firewall kost niets.. en heb nog genoeg (oude) hardware staan hiervoor.

>Hoe voorkom ik dat er Broadcast verkeer en dhcp packets vanaf het netwerk via de terminal server >niet bij ons productie netwerk komt? Vrees dat ik hier toch een firewall voor nodig ga hebben?

Die DHCP broadcast gaat niet door de terminal server heen hoor.
Bezie de TS als een "router" (niet niet route btw) en de DHCP broadcast komt niet verder als de 192.168.23.x NIC.

Zelfs wanneer ik zou besluiten om alles op 1 switch te zetten? (klanten bijv)

SpamLame schreef op donderdag 14 augustus 2008 @ 18:28:
Op de terminal server routing disablen zou afdoende moeten zijn om verkeer tussen de netwerken te voorkomen. Als je daarbovenop ip beveilings beleid (gpedit of een GPO) aansteekt op de TS zodat er ook alleen op de door jou gekozen poorten gecommuniceerd kan worden, dan zou een extra firewall wellicht overbodig zijn.

Routering uitzetten tussen de twee nics, kan ik toch geen verbinding meer opzetten vanaf productie naar testing vanaf de workstations in het productie netwerk?

[ Voor 23% gewijzigd door Workaholic op 14-08-2008 19:59 ]

[jvanhambelgium]

Audi-Addict schreef op donderdag 14 augustus 2008 @ 19:59:
[...]
Zelfs wanneer ik zou besluiten om alles op 1 switch te zetten? (klanten bijv)


Routering uitzetten tussen de twee nics, kan ik toch geen verbinding meer opzetten vanaf productie naar testing vanaf de workstations in het productie netwerk?

Euh, ik ben even niet meer mee...
Je TS heeft 2 NIC.
Je zet een RDP-sessie op naar je TS zodat je een desktop te zien krijgt. Dan ga je verder vanaf de TS en als je vb een tool zou laden die een IP connectie moet opzetten richting 192.168.x.x gaat dit werken hoor.
Je moet inderdaad IP-forwarding tussen de 2 NIC's afzetten als extra beveiliging.


Wat die DHCP betreft, je hebt toch altijd 2 switches ??? En als je slechts 1 fysische switch hebt heb je op z'n minst toch 2 VLAN's ?? Daar gaat de DHCP-broadcast niet door hoor.
Zoals ik je tekening zie zullen alle hosts op het 192.168.23.x LAN (in die onderste switch) wel degelijk de DHCP te horen krijgen (inclusief je TS) maar verder ook niet.

[SpamLame]

Audi-Addict schreef op donderdag 14 augustus 2008 @ 19:59:
...snip...

Routering uitzetten tussen de twee nics, kan ik toch geen verbinding meer opzetten vanaf productie naar testing vanaf de workstations in het productie netwerk?

Direct niet nee, maar dat was toch ook de bedoeling.
Als je van je WS naar de TS een RDP sessie opzet en in die sessie en nieuwe RDP,SSH (of wat dan ook) opzet naar je VM's dan heb je wat je wilde, een afgeschermd stuk netwerk maar toch te benaderen (middels een tussenstation).

[Workaholic]

Heren, het is volledig duidelijk.

@ Belgium, had je post verkeerd gelezen eerder, klopt helemaal wat je zegt .

We kunnen nu aan de slag Ben blij dat ik toch in de goede richting zat en jullie dit nog even bevestigen