ISA Server absichern

[StefanWe 14]

Hi,

ich hab jetzt seit einiger Zeit nen ISA 2004 Server bei mir in der Firma am laufen.

Habe heute mal nen Portscan mit NMAP gemacht. Da der ISA nicht mehr auf Pings von außerhalb reagiert muss man NMAP schon sagen, das er trotzdem scannen soll, ohne vorher zu pingen.

 

Das Ergebniss sieht dann so aus:

 

(The 1666 ports scanned but not shown below are in state: filtered)

PORT STATE SERVICE

80/tcp open http

135/tcp closed msrpc

137/tcp closed netbios-ns

138/tcp closed netbios-dgm

139/tcp closed netbios-ssn

1723/tcp open pptp

Device type: general purpose

Running: Microsoft Windows 2003/.NET

OS details: Microsoft Windows 2003 Server, Microsoft Windows 2003 Server SP1

 

Nmap finished: 1 IP address (1 host up) scanned in 263.187 seconds

wsstefan:/etc/ppp #

 

HTTP ist klar, da ich hier ne Weiterleitung auf meinen SBS Server mache.

PPTP ist ebenfalls klar, da der ISA als VPN Server fungiert. Doch kann ich die anderen Ports nicht schließen? Der RPC Dienst hat ja schon öfter zu Sicherheitsproblemen geführt. Genauso wie die Netbios Sachen.

 

Oder lassen diese sich nicht schließen?

Ebenfalls wär es nett, wenn man nicht unbedingt rausbekommt, das dort nen 2003er Server mitm SP1 läuft.

 

Etwas anderes:

 

Ist es möglich das Outlook Web Access vom SBS Server auf den ISA Server umzuziehen? Also das ich keine Weiterleitung mehr nutze, sondern den Webserver direkt publiziere?

Denn falls jemand einen Bug im IIS hat, ist dieser direkt auf dem SBS Server wo die Firmendaten liegen und der Gedanke gefällt mir überhaupt nicht.

Was bestrebt ihr noch so für Sicherheitsvorkehrungen? Und vor allem wie kann ich es am besten testen, ob meine Kiste sicher ist ?

[Christoph35 10]

Doch kann ich die anderen Ports nicht schließen? Der RPC Dienst hat ja schon öfter zu Sicherheitsproblemen geführt. Genauso wie die Netbios Sachen.

 

Soweit ich das sehe, sind die NetBIOS Ports doch geschlossen?

 

Ist es möglich das Outlook Web Access vom SBS Server auf den ISA Server umzuziehen?

 

Wenn Du eine Mail-Server-Publishing Regel erstellst, fungiert der ISA als Reverse-Proxy. D.h. er nimmt die Anfragen entgegen und gibt sie an Exchange auf deinem SBS weiter. Wenn Du das mit SSL machen willst (wovon ich jetzt mal ausgehe :D), musst Du das SSL-Zertifikat exportieren (mit privatem Schlüssel!) und auf dem ISA importieren. Du solltest dann beim Konfigurieren der Publishing Regel definieren, dass SSL-to-SSL Bridging gemacht werden soll; dann nimmt der ISA die ANfragen entgegen, entschlüsselt das ganze, kann seine Regeln checken (HTTP-Filter etc.) und schickt die Anfragen neu verschlüsselt zum SBS weiter.

 

Du kannst dann (sofern du nicht noch RPC/HTTPS machen willst), als Authentifizierung noch Forms Based Authentication einstellen.

 

Off-Topic:

Passt dieser Thread nicht besser in den Back-Office-Bereich?!

 

Christoph

[StefanWe 14]

mh naja es geht aber doch um Security oder?

 

 

Also ich wollt eigentlich keine SSL Verbindung. Denn auch dann ist ein Angreifer, falls er einen Bug im IIS findet direkt auf dem SBS Server hinter der Firewall.

 

Ist es nicht möglich auf der Firewall nen IIS zu installieren und hier das OWA drauf zu kopieren? Alle Pfade des OWA sollen aber auf den SBS zeigen? Denn so ist es einem Angreifer nicht so einfach möglich auf den SBS zu kommen, da der ISA Server nicht in der Domäne hängt.

[weg5st0 10]

Genau das ist aus Sicherheitsgründen nicht möglich. Der ISA Müsste dann Netzwerkzugriff auf die Datenbanken des Exchange haben.

Exchange und OWA lassen sich nicht trennen.

[Christoph35 10]

Was Du statt dessen machen könntest, wäre "zwischen" Exchange und ISA noch einen Front-End-Exchange zu stellen. Das kann mit E2K3 auch ein Standard-Exchange sein. Optimalerweise steht der auch im LAN, und nicht in einer DMZ.

 

Dann hättest Du den Client-Zugriff noch von den Mailbox-Servern getrennt.

 

Zum Thema Front-End/Back-End-Exchange Systeme schau Dir mal das MS-Whitepaper an:

Microsoft TechNet: Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology

 

Off-Topic:

@weg5st0: Eigentlich müsste deine Signatur anders lauten: deutsche KB Aritkel lassen ich auch auf Englisch anzeigen :D

 

Christoph

[StefanWe 14]

ohne mir jetzt das Whitepaper durchgelesen zu haben. Warum sollte der Front End ins Lan und nicht in die DMZ?

 

Ist die DMZ nicht genau dafür gedacht, das User aus dem Internet nicht ins Lan kommen, sondern nur bis zu den Servern in der DMZ?

 

Sprich die Zweite Firewall die das Lan von der DMZ trennt, verbietet den Zugriff von den Servern in der DMZ zum Lan ?Genauso andersrum, das niemand direkt vom Lan ins Internet kommt. Z.b. muss für HTTP Verkehr ja nen Proxy in der DMZ stehen worüber der Verkehr fließt. Bei Mails genauso, der Exchange darf ja nicht direkt ins Internet mailen, sondern über nen SMTP Relay in der DMZ ins Internet. Denn ansonsten könnte ja ein Angreifer direkt über Port 25 durch die DMZ ins Lan. Und die ganze DMZ bringt nichts.

 

Also aus dem Verständniss herraus würde ich den Front End Exchange in die DMZ stellen, die Mailboxen liegen im Lan. Das OWA liegt auf dem Front End in der DMZ.

Wenn nun nen User aus dem Lan mailt, geht die Mail über den Front End Server ins Internet. UNd nen Angreifer würds höchstens bis auf den Front End Server schaffen und hätte damit keinen Zugriff auf die Mailboxen.

 

 

Oder hab ich nen Denkfehler?

[Tallasar 10]

Hallo snoopy2004,

 

der Frontend sollte im LAN stehen, da Dieser die Authentifizierung an das AD weitergibt, dafür müßen eine unmenge Ports offen sein, welches sich mit mehreren Dömänen weiter erhöht. Steht dieser in der DMZ, müßtes Du diese Ports Alle an der Firwall öffnen und jeder Firewalladmin würde Dich dafür lynchen.

So arbeitet der ISA als ReverseProxy und baut einen SSL- Tunnel zum Frontend im LAN auf und das wäre mit 443 nur ein Port.

 

Gruß Tallasar

[StefanWe 14]

mh und ne elegantere Möglichkeit für eine DMZ gibt es nicht? Naja OK bei der SSL Verbindung kann man es ja sicherlich so einrichten, das nur Leute die dieses Zertifikat haben auf den ISA zugreifen können, korrekt?

 

Wobei dann dieser von überall Zugriff nicht gewährleistet ist. Denn in Inetkaffees hat man ja schlecht die Möglichkeit nen Zertifikat zu erstellen.

[Tallasar 10]

eine abgesicherte kaum.

So ist es .

Zugriffe über Internetkaffees sind ein Problem und bei uns im Konzern nicht erlaubt.

Eine Möglickeit wäre hier RSA, aber das ist eine ziemlich teure Angelegenheit.

 

Gruß Tallasar

[StefanWe 14]

Naja ok nen Konzern ist das hier nicht. Ne 2 Mann IT Bude.. aber man spielt ja gern mal rum.

 

Kann bzw. sollte man sonst noch etwas bei dem ISA Server absichern? Mal abgesehen von aktuellen Updates usw..

 

Durchstöbert ihr Seiten wie securityfocus.com usw und testet eure IT mit eventuellen Bugs bzw. Exploits?

[weg5st0 10]

Mit Bugs und Exploits zu testen ist gefährlich! Da kann schnell einiges kaputt gehen.

Vulnerability Scanner haben i.d.R. einen Soft und einen Hardmode (nessus kann auch Soft).

Dabei wird gescannt und eine Evt. Exploitanfälligkeit angezeigt. Dann kannst du reagieren und nach dem Patchen des Systems mit Exploits scannen.

[StefanWe 14]

nessus hab ich schon nen paar mal getestet.. ist es denn immer auf einem aktuellen Stand? Hat da jemand Erfahrungsberichte zu ?

Im Bereich Security beweg ich mich auf Neuland..