W2K12R2 Server Windows firewall, uitdaging

[Charlie932]

Windows Firewall issue:

Ik heb onderstaande situatie:

1 terminal server + 2 webservers in een domein / LAN (alle servers zijn Windows 2012 R2)

Nu zijn er op de terminal server verschillende mensen werkzaam, te verdelen in 2 AD groepen (webserverA en webserverB)

Op de terminalserver zijn beide URLs op te vragen (www.webserverA.nl + www.webserverB.nl).
Hoe kan ik het nu zo inregelen dat AD groep webserverA de url www.webserverA.nl kan openen, en AD groep webserverB de url www.webserverB.nl kan openen. Ze mogen echter niet bij de website van de andere AD groep!

Kortom de terminalserver zelf moet wel beide sites kunnen laten zien, maar enkel aan de juiste AD groep.
Hoe kan ik dit inregelen met de Windows firewall? Kan ik dit doen op de terminalserver, of dien ik de firewall aan te passen op de beide webservers?

Ik heb oa het volgende geprobeerd, maar krijg het niet werkend:
Op de webserverA een inboundfirewallrule gemaakt welke alles blokkeerd (alle poorten/services) en dan bij local pricipals een exeption gemaakt met AD groep webserverA erin. Deze mogen van mij immers wel door.

Helaas werkt dit niet.... beide sites worden gewoon weergegeven aan beide groepen.

Ook op de terminal server getracht een blokkeringsrule te maken voor AD groep webserverA richting het ip van webserverB en een tweede regel welke het omgekeerde doet; een blokkeringsrule voor AD groep webserverB richting het ip van webserverA. Ook dit krijg ik niet voor elkaar.


Welke manier zou moeten werken en hoe stel ik deze regel dan in?? Enig idee?

[Verwijderd]

Ik denk dat je daarvoor in Administrative Templates\ Windows Components\Internet Explorer moet zijn.

[Charlie932]

Of zou het moeten kunnen met een firewall GPO? En dan op basis van security filtering??

[Jazzy]

De firewall kun je niet per-user configureren, dus voor alle gebruikers geldt dezelfde configuratie. En ik denk ook niet dat je Internet Explorer kunt beperken tot het aanroepen van één website. Ik denk dat je een proxy-server nodig hebt waarmee je dit verkeer gaat regelen. Het afdwingen van die proxyserver doen je dan vervolgens weer met een GPO.

Of misschien zie ik nog een creatieve oplossing over het hoofd.

[Killah_Priest]

Charlie932 schreef op zondag 31 mei 2015 @ 14:52:
Of zou het moeten kunnen met een firewall GPO? En dan op basis van security filtering??

Hoe wil je dit dan precies voor elkaar krijgen?
Firewall GPO's zijn computer settings welke dus voor de machine gelden. Deze vallen dus volledig buiten de scope van user settings wat dat betreft.
Er is wel een optie om users te excluden voor een rule (hoewel zeer beperkt en alleen mogelijk op inboundrules icm een secure verbinding) : dit staat echter los van het feit dat een machine GPO alleen van toepassing is op machines en je dus niet aan kunt geven dat een computer GPO niet geld voor die groep gebruikers op dezelfde TS waardoor je weinig hebt aan security filtering.

(ISA en Forefront TMG kunnen dit volgens mij wel, jammer dat ze daarmee gestopt zijn)

[ Voor 5% gewijzigd door Killah_Priest op 31-05-2015 17:57 ]

[MichelatNL]

Kun je dit niet makkelijker in IIS met windows authentication en dan de juiste groep toegang geven?

[belrpr]

MichelatNL schreef op zondag 31 mei 2015 @ 18:05:
Kun je dit niet makkelijker in IIS met windows authentication en dan de juiste groep toegang geven?

Is inderdaad de juiste weg. Stel op u website in dat een bepaalde groep rechten heeft. Zodat alleen die groep de website kan zien

[Charlie932]

De IIS methode had ik ook al gezien..... nadeel is dat de webservers niet op IIS gebaseerd zijn. Dit is op basis van Qlikview. (aparte services)

[Semt-x]

Je kan de native Windows firewall standaard niet gebruiken als autorisatie.
een autorisatie laag kun je met een proxy toevoegen, mits de proxy AD-integrated is.
Bijv. TMG, maar die is end of life.

Naast een proxy kun je ook met IE instellingen en security filtering op GPO's een vergelijkbaar functionaliteit verkrijgen.
Echter, wil je dit (nagenoeg) dicht spijkeren moet je veel extra configureren. En als je het dan voor IE werkend hebt geregen, kan een gebruiker chrome.exe starten en alsnog die ‘verboden’ site bezoeken?
Ik denk dat het een onmogelijke missie is om dit goed te configureren.

De autorisatie voor de web-applicatie zou integraal onderdeel moeten zijn van die applicatie en niet gesimuleerd door configuratie eromheen.
Als de bouwer van die applicatie dit scenario niet ondersteund, is het tijd dit aan te kaarten bij diegene die dit pakket heeft gekozen zodat diegene het kan aankaarten bij de applicatie maker.

[Jazzy]

Semt-x schreef op maandag 01 juni 2015 @ 10:18:
Naast een proxy kun je ook met IE instellingen en security filtering op GPO's een vergelijkbaar functionaliteit verkrijgen.

Hoe?

[Semt-x]

De eerste oplossing valt of staat met de voorwaarde of gebruikers ook naar publieke internet sites kun/mogen surfen, dit is niet benoemd.
Als dat niet het geval is, zou het als volgt kunnen;

GPO voor App-A heeft security filter voor de App-A groep, Deze bevat proxy instelling naar 127.0.0.1 (of een ip-adres van een lokaal website, waarop staat dat surfen niet is toegestaan). En de URL van de applicatie waar men wel naartoe mag, staat in de proxy uitzonderingen.

De tweede oplossing, als men wel moet kunnen surfen, ligt er een mogelijkheid die afhankelijk is van eigenschappen van web app.
Bijv als deze bijzondere onderdelen nodig heeft om te kunnen werken zoals java / active-X / bijzondere provileges in IE.

Opnieuw een GPO met security filter voor de App-A groep. Die de site die niet bezocht mag worden toewijzen aan de IE “restricted sites” security zone. Waardoor de applicatie niet meer functioneert. Omdat die gebruik van active-X / java blokkeert.

Als ik meer details heb van de applicatie in kwestie zijn er vast nog extra “oplossingen” te vinden.

Zoals eerder gezegd, zijn deze “oplossingen” allemaal lap middelen om een ongeschikte applicatie bruikbaar te maken in dat scenario.
Daar ben ik faliekant op tegen omdat ze de Infra omgeving van een bedrijf onnodig complex maken.
Het geld dat men bespaart met een goedkopere oplossing deze extra instellingen behoeft. Wordt in de verdere toekomst in veelvoud uitgegeven aan complexiteit van upgrade / schoningstrajecten. Hoe groter het bedrijf, hoe groter de gevolgen.
Niet alleen het upgraden van de applicatie in kwestie in de toekomst wordt afhankelijk van externe instellingen (zoals GPOs) ook het upgraden van AD met GPO constructies en upgrades van IE lijden eronder.

[Oogje]

Charlie932 schreef op maandag 01 juni 2015 @ 08:26:
De IIS methode had ik ook al gezien..... nadeel is dat de webservers niet op IIS gebaseerd zijn. Dit is op basis van Qlikview. (aparte services)

Volgens mij ondersteunt Qlikview gewoon windows authentication.

Zie oa http://www.datamind.co.il...verview-EN.pdf?id=9521357

[ Voor 16% gewijzigd door Oogje op 01-06-2015 14:24 ]

[Question Mark]

Jazzy schreef op maandag 01 juni 2015 @ 11:25:
[...]

Hoe?

Restricted sites binnen Internet Explorer gaan instellen op basis van gebruikersgroepen met behulp van GPP's. Absoluut niet de meest nette oplossing, maar het werkt wel.

[Killah_Priest]

Oogje schreef op maandag 01 juni 2015 @ 14:23:
[...]

Volgens mij ondersteunt Qlikview gewoon windows authentication.

Zie oa http://www.datamind.co.il...verview-EN.pdf?id=9521357

Klopt, bij een klant van ons draait ook QV en dat hebben wij samen met de klant gewoon dichtgegooid met AD autorisatie voor users die er niets te zoeken hebben

[The Eagle]

Kan aan mij liggen, maar is dit niet met een simpele entry in de hosts file op te lossen

[bratos]

The Eagle schreef op maandag 01 juni 2015 @ 22:49:
Kan aan mij liggen, maar is dit niet met een simpele entry in de hosts file op te lossen

nee want als user X uit groep 1 aanmeldt krijgt ie de zelfde hostsfile als user Y uit groep 2. en dat moet juist niet zo zijn.
Dan moet je users een andere hosts file gaan geven in een restricted folder : veel gedoe.

Als de users niet op anders sites hoeven, kan je een dummy proxy opgeven en een exeption naar de toegestane url.

[johnkeates]

Reverse proxy met AD authenticatie en de sites alleen via die reverse proxy benaderbaar maken op IP niveau. Kan met haproxy, nginx, apache etc..

Dit heeft verder niks met firewalls te maken, die werken op host en connectie niveau, heeft niks met users te maken.


Wat je nodig hebt:

- Een server met een van de bovenstaande servers die reverse proxy mode ondersteunen
- Een manier zodat er geen HTTP of HTTPS verkeer tussen de servers met je applicatie en de terminal server kan plaatsvinden, bijvoorbeeld gescheiden subnet of een firewall regel die al het verkeer blokkert.

Configureer op je reverse proxy de sites, en configureer per site welke authenticatie en rol je verwacht. Dat kan op LDAP en Kerberos maar ook d.m.v. hardcoded groups en users.

[ Voor 77% gewijzigd door johnkeates op 01-06-2015 23:10 ]

[spone]

Misschien een idee om iedere website op een ander IP te zetten, en per IP een firewallregel aan te maken met de juiste authorisatie?

[johnkeates]

spone schreef op maandag 01 juni 2015 @ 23:06:
Misschien een idee om iedere website op een ander IP te zetten, en per IP een firewallregel aan te maken met de juiste authorisatie?

Nee. De firewall weet niet welke use bij welke connectie hoort.

[CH4OS]

Is het niet logischer om de gebruiker ongeacht de URL van website A of website B die zij intypen website A of website B voor te schotelen?

Dus dat een medewerker voor website A bij www.websitea.nl én www.websiteb.nl altijd website A te zien krijgt?

[ Voor 38% gewijzigd door CH4OS op 01-06-2015 23:11 ]

[Verwijderd]

Hang er een oplossing als websense voor. Kun je gewoon per AD groep policies maken met o.a access lists voor bepaalde websites.

[spone]

johnkeates schreef op maandag 01 juni 2015 @ 23:08:
[...]

Nee. De firewall weet niet welke use bij welke connectie hoort.

Hoezo niet? Windows Firewall weet dit prima. Op lokaal niveau in elk geval uitgaand, op domeinniveau ook inkomend.

[johnkeates]

Verwijderd schreef op maandag 01 juni 2015 @ 23:09:
Hang er een oplossing als websense voor. Kun je gewoon per AD groep policies maken met o.a access lists voor bepaalde websites.

Websense is dus gewoon een dure reverse proxy die niks toevoegt behalve een commercieel branding sausje en een blackbox binary met gratis backdoors Er zijn zo veel CVE's voor websense dat je beter af bent met een post-it note of mensen a.u.b. doen wat ze gezegd worden en hopen dat ze luisteren.

spone schreef op maandag 01 juni 2015 @ 23:14:
[...]

Hoezo niet? Windows Firewall weet dit prima. Op lokaal niveau in elk geval uitgaand, op domeinniveau ook inkomend.

Vreemd, je kan nergens rules maken waar je een user of group in mag instellen. Niet vergeten dat het een terminal server is he! Een firewall rule per-user via GPO of SSCM droppen werkt niet, want rules zijn globaal. Dus als je twee users hebt die allebei andere toegang hebben kan je geen rules gebruiken die gelijktijdig actief zijn.

[ Voor 35% gewijzigd door johnkeates op 01-06-2015 23:16 ]

[Verwijderd]

Poeh ik zit even te kijken, behoorlijk wat CVE's inderdaad. Ik heb het jaren gebruikt en was er altijd zeer tevreden over. Vooral de integratie met PIX en ASA fw's zorgde altijd voor een probleemloze implementatie.

[Ximon]

Ik snap niet goed waarom de gebruikerA websiteB niet mag zien/openen/whatever. Zijn het twee verschillende klanten die niets met elkaars omgeving te maken hebben? Dan zou ik iets met een reverse proxy gaan doen. Is authenticatie op de websites niet ingeregeld? Dan zou ik dat doen. Hoe dan ook, ik zou in ieder geval bij voorkeur niet op IP-basis dingen gaan doen, dit is geen laag 3 probleem IMO.

[Oogje]

Technisch gezien allemaal heel leuk en aardig, maar het is bij de bron (applicatie) al op te lossen.
Mijns inziens dus geen reden voor reverse proxy's of andere oplossing (wel leuk om uit te pluizen natuurlijk )

[Semt-x]

@Oogje, helemaal mee eens, jouw bijdrage is de enige juiste oplossing.
Autorisatie behoort in de applicatie en niet erom heen geknutseld.
Mijn aanname was dat TS dit al had uitgezocht, maar blijkbaar niet…

[Charlie932]

@Killah_Priest, Mag ik vragen hoe je dit gedaan hebt in QV ?? (dichtgegooien met AD autorisatie voor users die er niets te zoeken hebben)


@CptChaos, Men krijgt nu ook meteen de juiste site (via remoteapps).
Neemt niet weg dan men gewoon een andere url in de browser kan intikken...


@Ximon, inderdaad... betreft verschillende klanten in een hosted omgeving. Ze hebben niks op elkaar sites te zoeken. (Ze kennen ook geen andere url's dan hun eigen, maar toch qua security en ISO certificeringen zou men niet bij elkaars site moeten kunnen. Dat kan nu wel als je de verschillende url's weet)


Allen, bedankt naar jullie antwoorden zover..... ik neig naar een oplossing zoals die van "Semt-x". Ik ga IE limiteren zodat men bepaalde sites NIET kan bezoeken (restricted sites). Dit doe ik middels een GPO en deze GPO hang ik aan de juiste user OU (klantA)
Zo'n zelfde GPO met andere restrictie url's koppel ik dan uiteraard aan klantB.

Ik werk met remoteapps via een gateway. Men kan dus niet een andere browser gaan starten dan IE. Dat probleem vang ik op deze wijze gelukkig af.

Ik ben nog wel even benieuwd naar de oplossing van Killah_Priest...... wellicht kan ik ook per webserver iets met QV doen zodat deze al iets doet met AD authorisatie.

[Oogje]

Charlie932 schreef op dinsdag 02 juni 2015 @ 20:32:

@CptChaos, Men krijgt nu ook meteen de juiste site (via remoteapps).
Neemt niet weg dan men gewoon een andere url in de browser kan intikken.

Dat kun je met een GPO dichttimmeren. Zal morgen ff kijken welke setting dat ook alweer was.

[Killah_Priest]

Charlie932 schreef op dinsdag 02 juni 2015 @ 20:32:
@Killah_Priest, Mag ik vragen hoe je dit gedaan hebt in QV ?? (dichtgegooien met AD autorisatie voor users die er niets te zoeken hebben)


@CptChaos, Men krijgt nu ook meteen de juiste site (via remoteapps).
Neemt niet weg dan men gewoon een andere url in de browser kan intikken...


@Ximon, inderdaad... betreft verschillende klanten in een hosted omgeving. Ze hebben niks op elkaar sites te zoeken. (Ze kennen ook geen andere url's dan hun eigen, maar toch qua security en ISO certificeringen zou men niet bij elkaars site moeten kunnen. Dat kan nu wel als je de verschillende url's weet)


Allen, bedankt naar jullie antwoorden zover..... ik neig naar een oplossing zoals die van "Semt-x". Ik ga IE limiteren zodat men bepaalde sites NIET kan bezoeken (restricted sites). Dit doe ik middels een GPO en deze GPO hang ik aan de juiste user OU (klantA)
Zo'n zelfde GPO met andere restrictie url's koppel ik dan uiteraard aan klantB.

Ik werk met remoteapps via een gateway. Men kan dus niet een andere browser gaan starten dan IE. Dat probleem vang ik op deze wijze gelukkig af.

Ik ben nog wel even benieuwd naar de oplossing van Killah_Priest...... wellicht kan ik ook per webserver iets met QV doen zodat deze al iets doet met AD authorisatie.

Een collega van mij heeft het destijds gedaan (toen ik nog een junior beheerder was een aantal jaar terug).
Vandaag ben ik de gehele dag bij de betreffende klant dus ik zal wel even navraag doen bij degene die dat deel momenteel onderhoud (ik hou mij daar momenteel alleen nog maar echt met Powershell en Exchange bezig momenteel )

[Oogje]

Oogje schreef op dinsdag 02 juni 2015 @ 22:56:
[...]

Dat kun je met een GPO dichttimmeren. Zal morgen ff kijken welke setting dat ook alweer was.

Internet Explorer, Enforce Full Screen Mode.

[Ximon]

Een reverse proxy heeft meer voordelen dan alleen een extra (single-sign on) authenticatielaag:

• Toegang tot de applicatie vanaf de terminal servers wordt op alle mogelijke manieren gecontroleerd, in plaats van op slechts 1 (via de Internet Explorer die aan klanten beschikbaar gesteld wordt).
• De applicatie is makkelijker redundant te maken, zodat bijvoorbeeld bij onderhoud aan een applicatieserver niet direct de applicatie offline gehaald moet worden
• Beveiligingsproblemen in de webserver die in de applicatie ingebouwd zit (bijvoorbeeld: geen ondersteuning voor TLS, Heartbleed-achtige problematiek) leiden niet automatisch tot blootstelling aan deze problemen
• Beveiligingsproblemen in de webserver van de reverse proxy leiden niet automatisch tot updates of upgrades van de applicatie

Dit via GPOs of aan de applicatiekant fixen is makkelijker te reasliseren, maar lijkt me een minder robuuste oplossing.

EDIT: Ik doe trouwens de IE die de klanten gebruiken voor QV ook gebruikt wordt voor standaard webbrowsen etc.

[ Voor 5% gewijzigd door Ximon op 03-06-2015 09:28 ]

[Semt-x]

@charlie932 lees mijn bijdrage nog eens goed, want "restricted sites" doet iets anders dan je denkt.
Met kracht adviseer ik je geen knutsel oplossing te bouwen met GPO’s of (reverse) proxies.
Gebruik de ingebouwde autorisatie van de applicatie, zoals geopperd door Oogje.

Overigens is een reverse proxy oplossing niet per se een knutsel oplossing, omdat grote bedrijven _alle_ interne websites ontsluiten via een reverse proxy. Maar ik schat in dat dit bij jou niet van toepassing is, want anders had je hier geen advies gevraagd.

[Killah_Priest]

Helaas heb ik vandaag geen tijd gehad om dit te controleren (sorry TS) aangezien ik mij nu volledig moet gaan richten op een cross-forest migration inclusief Exchange. Hopelijk kan ik het volgende week even vragen als ik daar weer ben.

[Wolfwood]

Verleden jaar ben ik bij een klant ook bezig geweest met de security van Qlikview. Als ik het mij goed herinner wordt de AD-toegang toegepast op de folders waar de .qvd bestanden instaan. Gebruikers die geen rechten hebben op die mappen, kregen de betreffende bestanden ook niet te zien (of kregen Access Denied, dat weet ik niet meer goed).
Toegang werd dus gewoon op Windows niveau geregeld. Hiervoor moet in Qlikview wel een bepaalde optie aangepast worden, en die ken ik niet meer van buiten.

[Charlie932]

Oogje schreef op woensdag 03 juni 2015 @ 09:06:
[...]


Internet Explorer, Enforce Full Screen Mode.

GENIAAL! Zeer weinig inspanning en het voldoet aan de wensen van deze omgeving!!
Men krijgt meteen de juiste site voor geschoteld, en kan niet meer naar een andere site doordat de url eenvoudig weg niet is in te tikken. (en nee andere browsers openen kan ook niet, men krijgt remoteapps voorgeschoteld en geen full desktop)

[ Voor 32% gewijzigd door Charlie932 op 03-06-2015 22:09 ]

[Charlie932]

Semt-x schreef op woensdag 03 juni 2015 @ 09:45:
@charlie932 lees mijn bijdrage nog eens goed, want "restricted sites" doet iets anders dan je denkt.

@semt-x, je had gelijkt.... ik zei restricted sites, maar dit doet inderdaad niet wat ik wilde.
Het kan echter wel op een soort gelijke manier als jij aangaf, via de content tab, zie hier:

http://www.windowsecurity...r-Using-Group-Policy.html


@Allen, bedankt zover! Ik hoop dat de gpo met full restricted mode in IE voldoet
(http://www.askvg.com/tip-...net-explorer-web-browser/)

Lijkt goed voor zover ik het nu lees! BEDANKT!

[Verwijderd]

Volgens mij kan je het een en ander prima op lossen door PAC files te gebruiken zonder daarbij gebruik te maken van een proxy. Ik heb in het verleden ook PAC files gebruikt om hosts te blokkeren dan wel toe te staan.

How to Configure Proxy Settings Using Group Policy Management:

https://techlib.barracuda.com/wss/configureproxyusinggp

Voorbeeldjes om verkeer toe te staan en te blocken met PAC files:

http://www.schooner.com/~loverso/no-ads/

https://calomel.org/proxy_auto_config.html

[Oogje]

Charlie932 schreef op woensdag 03 juni 2015 @ 22:06:
[...]


GENIAAL! Zeer weinig inspanning en het voldoet aan de wensen van deze omgeving!!
Men krijgt meteen de juiste site voor geschoteld, en kan niet meer naar een andere site doordat de url eenvoudig weg niet is in te tikken. (en nee andere browsers openen kan ook niet, men krijgt remoteapps voorgeschoteld en geen full desktop)

Geen dank, succes met t inrichten