[SBS2000] ISA-server blokkeert applets

[Verwijderd]

Situatie:
Heb een klein netwerk met een server. Server draait met SBS2000 en wordt niet alleen gebruikt als server, maar ook als reserve-werplek. Alles draait prima, met 1 uitzondering.

Het probleem:
Op der server wordt dus wel eens gewerkt en ook gesurft.
Wannneer een internetpagina gebruik maakt van een (Java-)applet, wordt deze applet geblokkeerd door de ISA-server. Een voorneeld hiervan is de internet site van de Postbank, wanneer je in moet loggen.
Op de webserver draait een site en op 1 van de pagina's van de site wil ik een java-applet plaatsen. Intern werkt de applet prima, maar wanneer iemand in de Wijde Wereld de pagina bezoekt, ziet die alleen maar een rood kruisje. Overigens werken Flash-pagina's wel.
Op de server draait geen firewall-client, omdat dat regelmatig problemen geeft met de webserver en de DNS-server. Clients met de FWC hebben totaal geen probleem.

Akties ondernomen:
Ik heb de content groups aangepast zodat die alle apllets door zouden moeten laten.(application/*)
Ik heb het probleem aan Google voorgelegd, maar daar krijg hoofdzakelijk antwoorden over Java-applets die om een gebruikersnaam/wachtwoord vragen. Dat probleem heb ik dus niet.
Het probleem aan de GoT-search voorleggen, maakte me ook al niet wijzer.

Vraag:
Hoe los ik dit op?

[paulhekje]

Wat zegt de logging van ISA ? (firewall of proxylog afhankelijk van je rules)

opmerking over content blocking:
ik heb de ervaring dat blocken op mimetype (application/*) niet foutloos werkt. Vaak bieden servers een ander mimetype aan dan wat de data eigenlijk is.
Dus test een keer met alle content blocking rules uit.

Soms is het op te lossen door via het register de blockmethode op file-extensie te zetten, maar dit kan weer als nadeel hebben dat bijv. cgi scripts met de extensie .exe worden geblocked.

[ Voor 74% gewijzigd door paulhekje op 15-03-2005 09:07 ]

[Rolfie]

Gebruik je authenticatie op je proxy server? De kans is groot dat hier je fout in zit.

[Verwijderd]

Offtopic replies getrashed, gelieve ontopic verder te gaan.

[Koffie]

Blokkeert ISA die Applets alleen *op* de server zelf, of op elke client in je LAN

[Edwin van Cleef]

Mischien rare vraag maar is dit iets van de laatste tijd?
Een bepaalde update zou namenlijk ook voor een block van een app kunnen zorgen.
Dat heb ik hier ondervonden met scripts lezen van cd (studiecd's)
Dit word meestal toegewijd aan security dus de beveiliging van je software op de server met name het os

[Verwijderd]

paulhekje schreef op dinsdag 15 maart 2005 @ 07:46:
Wat zegt de logging van ISA ? (firewall of proxylog afhankelijk van je rules)

opmerking over content blocking:
ik heb de ervaring dat blocken op mimetype (application/*) niet foutloos werkt. Vaak bieden servers een ander mimetype aan dan wat de data eigenlijk is.
Dus test een keer met alle content blocking rules uit.

Soms is het op te lossen door via het register de blockmethode op file-extensie te zetten, maar dit kan weer als nadeel hebben dat bijv. cgi scripts met de extensie .exe worden geblocked.

Ik heb het HTTP Redirector Filter uitgezet, maar dit geeft geen resultaat. De content-filters kan ik alleen maar verwijderen. Wanneer dit niet helpt, moet ik alle filters handmatig aanmaken. Heb jij een suggestie?

Rolfie schreef op dinsdag 15 maart 2005 @ 08:50:
Gebruik je authenticatie op je proxy server? De kans is groot dat hier je fout in zit.

Nee, ik gebruik geen authenticatie. De bezoekers van de webserver krijgen dus ook geen vraag om user/pass voor de pagina en/of applet.

Koffie schreef op dinsdag 15 maart 2005 @ 15:11:
Blokkeert ISA die Applets alleen *op* de server zelf, of op elke client in je LAN

Het gaat alleen om de server. Als ik op de clients de FWC uitzet, worden applets gewoon doorgelaten en gebruikt.

Edwin van Cleef schreef op dinsdag 15 maart 2005 @ 15:16:
Mischien rare vraag maar is dit iets van de laatste tijd?
Een bepaalde update zou namenlijk ook voor een block van een app kunnen zorgen.
Dat heb ik hier ondervonden met scripts lezen van cd (studiecd's)
Dit word meestal toegewijd aan security dus de beveiliging van je software op de server met name het os

Het speelt zich allang af, maar was nooit hinderlijk. Internetbankieren gebeurde gewoon op een client. Maar nu applets op de eigen server niet 'naar buiten' gaan, is het pas een 'echt' porbleem.

[Rolfie]

Het probleem zit hem in je paketfilter settings van ISA

Wat gebeurt er :
IE download alles via de proxy en doet daarom een bypass van de packetfilter firewall van ISA.

Waarschijnlijk doet de java applet een directe benadering naar de server (dus niet door de proxy heen).
Maak een een outbound Packet Filter voor TCP/IP Port 80 en TCP/IP port 443. Dit moet je probleem oplossen

[Verwijderd]

Op de ISA Server zelf werken de Protocol Rules zoals je die voor de clients instelt niet daar requests niet door de proxy gaan, zoals Rolfie zegt. Je zult dus voor gebruik op de server harde Packet Filters aan moeten maken.

[Verwijderd]

Ik heb zojuist IP Packet Filters aangemaakt voor poorten 80 en 443, voor zowel in- als outbound, maar zonder resultaat. De melding van IExplorer in de statusbalk op de server:
load: class xxxxxxx.class not found.

edit:
Ik heb al eerder Packet Filters gemaakt, om zo nieuwsgroepen vanaf de server te kunnen bezoeken. Deze werken probleemloos. Later heb ik voor een test Shoutcast geïnstalleerd om presentaties live te kunnen broadcasten, maar dit kreeg ik maar gedeeltelijk aan de praat.

[ Voor 41% gewijzigd door Verwijderd op 15-03-2005 20:07 ]

[Rolfie]

Kan dit niet een probleem van de nieuwe IE beveiliging zijn? Kan je die eventueel eens deinstalleren? Eens kijken of dit helpt.

[Verwijderd]

Rolfie schreef op dinsdag 15 maart 2005 @ 21:58:
Kan dit niet een probleem van de nieuwe IE beveiliging zijn? Kan je die eventueel eens deinstalleren? Eens kijken of dit helpt.

Het staat los van IE. Mensen die m'n webserver bezoeken, krijgen een rood kruisje op de plaats waar een java-applet hoort te draaien. Wanneer ik m'n eigen webserver bezoek via het interne adres, i.p.v. het internetadres, werkt de applet wel.

Heb even de errorlog van de JavaConsole geplaatst. Misschien dat iemand hier iets in ziet wat ik niet zie....

code:

java.lang.ClassNotFoundException: java.net.ConnectException: Connection refused: connect

    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.PlainSocketImpl.doConnect(Unknown Source)
    at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
    at java.net.PlainSocketImpl.connect(Unknown Source)
    at java.net.Socket.<init>(Unknown Source)
    at java.net.Socket.<init>(Unknown Source)
    at sun.net.NetworkClient.doConnect(Unknown Source)
    at sun.plugin.protocol.jdk12.http.HttpClient.doConnect(Unknown Source)
    at sun.net.www.http.HttpClient.openServer(Unknown Source)
    at sun.net.www.http.HttpClient$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.net.www.http.HttpClient.privilegedOpenServer(Unknown Source)
    at sun.net.www.http.HttpClient.openServer(Unknown Source)
    at sun.net.www.http.HttpClient.<init>(Unknown Source)
    at sun.net.www.http.HttpClient.<init>(Unknown Source)
    at sun.plugin.protocol.jdk12.http.HttpClient.<init>(Unknown Source)
    at sun.plugin.protocol.jdk12.http.HttpClient.New(Unknown Source)
    at sun.plugin.protocol.jdk12.http.HttpURLConnection.privBlock(Unknown Source)
    at sun.plugin.protocol.jdk12.http.HttpURLConnection$PrivilegedBlockAction.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin.protocol.jdk12.http.HttpURLConnection.connect(Unknown Source)
    at sun.plugin.protocol.jdk12.http.HttpURLConnection.getInputStream(Unknown Source)
    at java.net.HttpURLConnection.getResponseCode(Unknown Source)
    at sun.applet.AppletClassLoader.getBytes(Unknown Source)
    at sun.applet.AppletClassLoader.access$100(Unknown Source)
    at sun.applet.AppletClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.applet.AppletClassLoader.findClass(Unknown Source)
    at sun.plugin.security.PluginClassLoader.access$201(Unknown Source)
    at sun.plugin.security.PluginClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadCode(Unknown Source)
    at sun.applet.AppletPanel.createApplet(Unknown Source)
    at sun.plugin.AppletViewer.createApplet(Unknown Source)
    at sun.applet.AppletPanel.runLoader(Unknown Source)
    at sun.applet.AppletPanel.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

[ Voor 76% gewijzigd door Verwijderd op 16-03-2005 13:48 ]

[Rolfie]

Krijg je iets te zien in je ISA logging? Daar zou iets moeten staan waarom je er niet door mag gaan?

[Verwijderd]

Je applet probeert een HTML pagina op te vragen die niet bereikbaar is. Benaderd de applet niet een server via een intern IP adres?

[Verwijderd]

@Rolfie: Ik zie nergens in de ISA logs dat er een applet geblokkeerd wordt.

@Jan Klaasen: Het bovenstaande logfile is gemaakt toen ik vanaf IE op de server een pagina met een applet benaderde. Het gaat om deze pagina, waar verschillende applet aangeboden worden. Hiermee heb ik gekeken of er applets zijn, die wel worden doorgelaten om uit te sluiten of het aan bepaalde applets lag. Geen van de applets kan ik zien en dus allemaal dezelfde melding in de java-console.

[paulhekje]

Deze vraag heb ik al eerder gesteld: Wat zegt de logging van ISA ? (firewall of proxylog afhankelijk van je rules)
Daarin staat het antwoord waarom/wat wordt geblocked.

[Rolfie]

Ik verwacht toch dat er ergens een blockkering actief is op je ISA servers.

Staat de proxy server aangevinkt op je werk station? Zo ja zet deze dan eens uit. Wat doet die dan?. Als je eventueen eens de proxy client installeerd op een werkstation (dus niet op de server), werkt het dan wel goed?

[ Voor 30% gewijzigd door Rolfie op 22-03-2005 09:04 ]

[Verwijderd]

@paulhekje: In de logfile van de proxy is weinig te vinden. Voor de volledigheid heb ik hier een stukje uit het logfile. Dit stukje betreft een site met java-applets. Je ziet in de log dat de .class wel gevonden worden, maar dat een stap later de mime-type veranderd en dat ie dan onvindbaar is.

@Rolfie: Het probleem doet zich alleen voor op de server. Op de werkstations werkt alles wel goed, met of zonder FWC.

[Verwijderd]

zoek eens op isaserver.org. daar staat een howto om website "buiten" de proxy om te laten lopen.

overigens gaat dit allemaal weer tegen alle security regels in. surfen op een isabak die ook nog eens dc is...

[Verwijderd]

Ik heb IIS al buiten de proxy omlopen. De site draait netjes op poort 80 en is ook voor iedereen bereikbaar. Da's meteen ook het vreemde, dat een applet op de site niet aangesproken kan worden. De client die buiten zit, kan het bestand niet vinden. Wanneer ik intern naar de site ga om het .class-bestand te downloaden via het www-adres, kan ik het bestand ook niet downloaden. Als ik de server aanspreek met de servernaam, dan kan ik het .class-bestand wel downloaden.

[Verwijderd]

dus je hebt geen gebruik gemaakt van de "web publishing rules" (reverse proxy), maar simpelweg de porten geforward (al het verkeer 1 op 1 doorzetten). je proxylog doorzoeken heeft dan natuurlijk ook geen zin...

als je dat gedaan hebt en je een gewone html/asp (hello world) pagina wel kan opvragen, zit het niet in isa. ik zou het dan ook eerder gaan zoeken in een name resolving problem.

[Verwijderd]

Ik ga binnenkort de server compleet opnieuw installeren. Ik denk dat dat nog de enige oplossing is om de boel werkend te krijgen. Ik heb ook een post in microsoft.public.is lopen, maar ook daar nog geen oplossing. Blijkbaar is het niet een veel vorkomend probleem.