Shandurai 10 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 Hallo NG Mir hats jetzt echt die Sprache verschlagen... Wir haben vor einiger Zeit ein Firewallsystem eines Neukunden übernommen... Folgendes muss man sich dabei vorstellen: 1. any zwischen allen Netzbereichen 2. 2/3 des Regelwerks bestand aus Testregeln die nicht mehr bereinigt wurden, die auch nur zum Teil funktionieren konnten 3. VPN Zugang wurde vom vorherigen Dienstleister als zu umständlich empfunden und daher entweder ausgeredet (???) oder absichtlich nicht zum Laufen gebracht (???)... man weiß es nicht 4. und nun die Härte: any Zugriff auf eine DMZ mit Exchange Servern von bestimmten öffentlichen IP Bereichen (VPN hat ja nicht funktioniert ;-) ) ... jetzt haben wir die Firewall komplett neu aufgebaut, VPN implementiert und nun sagt der Kunde, dass die Arbeit früher mit Outlook wesentlich einfacher war... ist ja kein Wunder bei any... Er fragt mich nun nach meinen Sicherheitsbedenken, wenn Exchange von öffentlichen IP Bereichen aus komplett zugänglich ist :suspect::suspect::suspect: Ich bin platt.... da fragt man sich, warum VPN so kompliziert sein sollte? Wo denn bitte? Wir haben uns ja schon auf PPTP "geeinigt", statt L2TP / IPSec Weiß jemand etwas Internet-Literatur, wo man Angriffsmöglichkeiten nachlesen kann, die z.B. auf den 4. Punkt abzielen? Für den Kunden "scheint" es sicher zu sein, weil ja nur bestimmte IP Bereiche zugreifen können. Den Aspekt des unverschlüsselten Datenverkehrs lässt er dabei gerne ausser Acht, ist ja bisher nichts passiert :suspect: Aber welche anderen Möglichkeiten gibt es, sowas auszunutzen? Besten Dank (...etwas platter) HemLock Zitieren Link zu diesem Kommentar
NorbertFe 1.809 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 Hallo NG Mir hats jetzt echt die Sprache verschlagen... Wir haben vor einiger Zeit ein Firewallsystem eines Neukunden übernommen... Folgendes muss man sich dabei vorstellen: 1. any zwischen allen Netzbereichen 2. 2/3 des Regelwerks bestand aus Testregeln die nicht mehr bereinigt wurden, die auch nur zum Teil funktionieren konnten 3. VPN Zugang wurde vom vorherigen Dienstleister als zu umständlich empfunden und daher entweder ausgeredet (???) oder absichtlich nicht zum Laufen gebracht (???)... man weiß es nicht 4. und nun die Härte: any Zugriff auf eine DMZ mit Exchange Servern von bestimmten öffentlichen IP Bereichen (VPN hat ja nicht funktioniert ;-) ) ... jetzt haben wir die Firewall komplett neu aufgebaut, VPN implementiert und nun sagt der Kunde, dass die Arbeit früher mit Outlook wesentlich einfacher war... ist ja kein Wunder bei any... Er fragt mich nun nach meinen Sicherheitsbedenken, wenn Exchange von öffentlichen IP Bereichen aus komplett zugänglich ist :suspect::suspect::suspect: Ich bin platt.... da fragt man sich, warum VPN so kompliziert sein sollte? Wo denn bitte? Wir haben uns ja schon auf PPTP "geeinigt", statt L2TP / IPSec Weiß jemand etwas Internet-Literatur, wo man Angriffsmöglichkeiten nachlesen kann, die z.B. auf den 4. Punkt abzielen? Für den Kunden "scheint" es sicher zu sein, weil ja nur bestimmte IP Bereiche zugreifen können. Den Aspekt des unverschlüsselten Datenverkehrs lässt er dabei gerne ausser Acht, ist ja bisher nichts passiert :suspect: Aber welche anderen Möglichkeiten gibt es, sowas auszunutzen? Besten Dank (...etwas platter) HemLock :) Grins. Gut, ich dachte nur ich erlebe solche Stories ;) Allerdings ist das schon wirklich hart, was du erzählst. Wie wärs denn, wenn du dem Kunden RPC over https vorschlägst. Das erspart ihm die VPN Konfiguration und ist mehr oder weniger genauso einfach wie bisher. Zum Thema Exchangeserver in DMZs sag ich jetzt lieber nichts, sonst kannst du deinen Kunden gleich mal darüber auch noch aufklären, dass diese DMZ eh für die Katz ist. Bye Norbert Zitieren Link zu diesem Kommentar
Shandurai 10 Geschrieben 9. Mai 2008 Autor Melden Teilen Geschrieben 9. Mai 2008 Hallo Norbert wenn Du DER Norbert aus den NG's bist bin ich ja froh dich hier auch anzutreffen ;) Also die DMZ wurde ursprünglich so benannt, weil die Firewall ihre Interfaces so bennent... Ich habe das ganze nun aber umbenannt in intern2... Bei intern1 und intern2 handelt es sich um zwei interne Netze, intern2 mit Windows Systemen, intern1 mit "feindlichen" Systemen ;) ...das zur Erklärung. Es ist nicht so, dass der Exchange in die DMZ gestellt wurde, seine Clients und DC's aber woanders stehen... RPC over HTTPS ist eine Möglichkeit, auch die einzige, die mir einfällt, die gewöhnte Arbeitsweise nicht zu verändern. Big Problema: Wir machen zwar die Firewall, nicht aber die internen Systeme... aber drauf hinweisen kann ich ja... Hmm ein ISA wird wohl nicht drin sein ("wir haben ja schon eine Firewall") dann muss es der Exchange halt selbst managen. ...und (oh graus!) die DNS Infrastruktur ist nicht nur "renovierungsbedürftig", die ist sanierungsbedürftig! Und dann noch Split-DNS... Nur was soll man nun sagen auf die Frage, welche Sicherheitsbedenken man hat? Dass es kein anderes Unternehmen, welches Geld für Sicherheit ausgibt, so machen würde?:eek: Dass man mal den Datenschutzbeauftragten fragen sollte? Soll ich nun ein Gesetzbuch zücken? Ich mach erstmal Mittag, bin echt fertig Grüße! Zitieren Link zu diesem Kommentar
NorbertFe 1.809 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 Hallo Norbert wenn Du DER Norbert aus den NG's bist bin ich ja froh dich hier auch anzutreffen ;) Jupp der bin ich. Also die DMZ wurde ursprünglich so benannt, weil die Firewall ihre Interfaces so bennent... Ich habe das ganze nun aber umbenannt in intern2... Bei intern1 und intern2 handelt es sich um zwei interne Netze, intern2 mit Windows Systemen, intern1 mit "feindlichen" Systemen ;) ...das zur Erklärung. Es ist nicht so, dass der Exchange in die DMZ gestellt wurde, seine Clients und DC's aber woanders stehen... OK, wobei selbst das im Normalfall ja eher kontraproduktiv ist (in meinen Augen, aber naja, da lasse ich mit mir diskutieren). ;) RPC over HTTPS ist eine Möglichkeit, auch die einzige, die mir einfällt, die gewöhnte Arbeitsweise nicht zu verändern. Big Problema: Wir machen zwar die Firewall, nicht aber die internen Systeme... aber drauf hinweisen kann ich ja... Also ich würde mir an deiner Stelle mal eine Liste anlegen, in der ich meine Bedenken an der gesamten Konfiguration (so wie sie dir jetzt bekannt ist und sich darstell) formuliert sind. Gleichzeitig mußt, du wie du ja sagst, ein paar argumente finden, die den Kunden davon überzeugen, dass Sicherheit sehr wohl etwas ist, was nicht per <Knopf an> einfach mal so herzustellen ist. RPC Veröffentlichungen ins Internet (auch wenns nur bestimmte Bereiche sind) sind immer kritisch. Hat denn immer noch nicht jeder mitbekommen was Blaster war? Nachteil dieser Lösung ist ja, dass das Arbeiten mit Outlook auch nur von vorher definierten Standorte möglich ist. Also schonmal nicht Active Sync, oder wirklich mobiles Outlook. Hmm ein ISA wird wohl nicht drin sein ("wir haben ja schon eine Firewall") dann muss es der Exchange halt selbst managen. Welche Firewall steht denn dort jetzt im MOment? Ansonsten kann ein Exchange das halt auch alleine (je nach Größe des Unternehmens und Risikoabschätzung). Aber selbst wenn der Exchange das alleine handhabt, ist das in meinen Augen noch besser als RPC offen im Internet (teile davon). ;) ...und (oh graus!) die DNS Infrastruktur ist nicht nur "renovierungsbedürftig", die ist sanierungsbedürftig! Und dann noch Split-DNS... Naja split DNS hab ich auch. Wenn man weiß, was man tut, tut das gut. Nur was soll man nun sagen auf die Frage, welche Sicherheitsbedenken man hat? Dass es kein anderes Unternehmen, welches Geld für Sicherheit ausgibt, so machen würde?:eek:Dass man mal den Datenschutzbeauftragten fragen sollte? Soll ich nun ein Gesetzbuch zücken? erstmal obige argumente (Mobility) besser handhabung mehr features. Das Gesetzbuch Verpflichtungen des Unternehmers usw. sollte man zumindest mal fallen lassen. ;) (Aber da kann man in Foren jetzt schlecht beraten) Viel Erfolg jedenfalls. Allerdings kann aus so einer Ausgangssituation auch ein gutes Projekt werden. Man muß halt den Kunden erstmal von seiner seit Jahren vorgehärteten Meinung (Weltbild) abbringen und ihm auch klar machen, dass man natürlich damit sein Geld verdient. (Leider helfen Autovergleiche TÜV usw. ja eher selten). ;) Bye Norbert Zitieren Link zu diesem Kommentar
Velius 10 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 Problem bei dieser Konfig ist, dass alle Dienste die im Status 'Listening' sind auf dem Stack theoretisch verwundbar sind, und das in dreierlei Hinsicht: Administrativ Z.B. Schwache Admin Passwörter, sollte die Datei und Druckfreigabe ein sein (weiss jetzt spontan nicht, ob der IPC$ erreichbar wäre so, oder ob RPC reicht) Über known/unknown Exploits Alle ungeflickten Lücken sind voll ausnutzbar. DoS & DDoS Attacken Sofern keine Firewall davor die das kann, anfällig gegen Ping-of-Death, land und/oder TCP-Syn Attacken usw., aber auch gegen HTTP DDoS Anfragen (IIS auf Exchange Pflicht) beispielsweise Da gibt's noch Tonnen von anderen Angriffsvektoren. Sowas ist grob fahrlässig. cheers Velius Zitieren Link zu diesem Kommentar
NorbertFe 1.809 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 Sowas ist grob fahrlässig. Was sagt der Kunde in so einem Fall? ;) "Bisher gabs noch nie Probleme..." Bin schon weg... Bye Norbert Zitieren Link zu diesem Kommentar
Shandurai 10 Geschrieben 9. Mai 2008 Autor Melden Teilen Geschrieben 9. Mai 2008 Hallo allerseits... Administrativ Z.B. Schwache Admin Passwörter, sollte die Datei und Druckfreigabe ein sein (weiss jetzt spontan nicht, ob der IPC$ erreichbar wäre so, oder ob RPC reicht) Über known/unknown Exploits Alle ungeflickten Lücken sind voll ausnutzbar. DoS & DDoS Attacken Sofern keine Firewall davor die das kann, anfällig gegen Ping-of-Death, land und/oder TCP-Syn Attacken usw., aber auch gegen HTTP DDoS Anfragen (IIS auf Exchange Pflicht) beispielsweise Gilt das auch wenn die Firewall den Verkehr (also auch RPC) nur von bestimmten IP Adressen erlaubt? Es ist nicht das gesamte Internet freigegeben! ...und das ist die Argumentation des Kunden Das was er noch meint ist, dass der Verkehr nicht verschlüsselt wird, aber welcher Angreifer hat schon die Möglichkeit an zentraler Stelle Daten abzufangen? Oder welcher Angreifer hat schon die Möglichkeit wieder an zentraler Stelle Daten zu verändern? Zitieren Link zu diesem Kommentar
Velius 10 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 Schon mal was von Man-in-the-middle-attack gehört? Das ist wohl der einfachste Angriffsverktor indiesem Szenario. Ausserdem, diese öffenlichen IPs und die dahinter liegenden wahrscheinlich geNATeten Verbindungen, sind diese gemaneged? Wohl kaum, oder? Zitieren Link zu diesem Kommentar
Shandurai 10 Geschrieben 9. Mai 2008 Autor Melden Teilen Geschrieben 9. Mai 2008 Hey Velius :) Schon mal was von Man-in-the-middle-attack gehört? Das ist wohl der einfachste Angriffsverktor indiesem Szenario. ja, ich lege mir nur grad meine Argumentation zurecht Ausserdem, diese öffenlichen IPs und die dahinter liegenden wahrscheinlich geNATeten Verbindungen, sind diese gemaneged? Wohl kaum, oder? ich nehme nicht das "oder", eher "das wohl kaum" :D aber auch hier ist es mal wieder so... "das ist mein lieber mitarbeiter, dem vertraue ich, bei dem ist bisher noch nie ein virus erkannt worden..." ...so oder so ähnlich wirds kommen :( ..aber ein guter punkt, ist notiert! ;) #edit wobei mir grad einfällt, dass das bei der nutzung eines vpn's nicht helfen würde... danke erstmal euch beiden! Zitieren Link zu diesem Kommentar
NorbertFe 1.809 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 aber auch hier ist es mal wieder so... "das ist mein lieber mitarbeiter, dem vertraue ich, bei dem ist bisher noch nie ein virus erkannt worden..." ...so oder so ähnlich wirds kommen :( Und die haben immer die gleichen festen IPs? Dann spricht doch eigentlich noch viel weniger dafür es so zu belassen. Denn dann kann man eigentlich mit Site2Site VPN arbeiten. #editwobei mir grad einfällt, dass das bei der nutzung eines vpn's nicht helfen würde... VPNs sind aber authentifiziert. So wie es jetzt ist, kann sich jeder darauf klinken. OK, bei Site2Site VPN wäre ebenfalls Aufwand zu betreiben... Aber ich schrieb ja schon: Sicherheit ist kein schalter, den man an oder aus schaltet. ;) Bye Norbert Zitieren Link zu diesem Kommentar
Velius 10 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 #edit wobei mir grad einfällt, dass das bei der nutzung eines vpn's nicht helfen würde... Darum wäre RPC-over-HTTPS gut: Auf deiner Seite kannst dann alles dicht machen ausser SSL. Was für 'ne Firewall ist es denn? Es gibt welche, da kannst du nach den GUIDs der RPC-Calls filtern ohne Ports dicht/auf zu machen, und auch innerhalb VPN. Das wäre dann wieder was, sollte dir das andere Netz zu unsicher sein. Zitieren Link zu diesem Kommentar
Shandurai 10 Geschrieben 9. Mai 2008 Autor Melden Teilen Geschrieben 9. Mai 2008 ich wieder... ...und (oh graus!) die DNS Infrastruktur ist nicht nur "renovierungsbedürftig", die ist sanierungsbedürftig! Und dann noch Split-DNS... Naja split DNS hab ich auch. Wenn man weiß, was man tut, tut das gut. Also Split-DNS ist nicht das schlimme, ich liebe Split-DNS sozusagen... nachdem man auf isaserver.org damit ja mehr als genug zu tun hat! Ich habe nur grad ein Teil der DNS Zonen (auszugsweise) gesehen, das reicht schon :( Viel Erfolg jedenfalls. Allerdings kann aus so einer Ausgangssituation auch ein gutes Projekt werden. Man muß halt den Kunden erstmal von seiner seit Jahren vorgehärteten Meinung (Weltbild) abbringen und ihm auch klar machen, dass man natürlich damit sein Geld verdient. (Leider helfen Autovergleiche TÜV usw. ja eher selten). Erfolg kann ich brauchen! Ich sag ja, da gibts "feindliche" Systeme... und wie lang es da braucht von etwas zu überzeugen, muss ich ja nicht erwähnen ;) #editwobei mir grad einfällt, dass das bei der nutzung eines vpn's nicht helfen würde... VPNs sind aber authentifiziert. So wie es jetzt ist, kann sich jeder darauf klinken. OK, bei Site2Site VPN wäre ebenfalls Aufwand zu betreiben... Ich glaub der Kunde "authentifiziert" noch analog... "Das ist mein Mitarbeiter, dem vertrau ich!" na mal sehen... Was für 'ne Firewall ist es denn? Es gibt welche, da kannst du nach den GUIDs der RPC-Calls filtern ohne Ports dicht/auf zu machen, und auch innerhalb VPN. Das wäre dann wieder was, sollte dir das andere Netz zu unsicher sein. Hmm über Firewalls redet man nicht gerne ;) Im Grunde wird die Firewall als reiner Portfilter benutzt, ich würde dem System nicht viel Intelligenz (wie ISA Server) zusprechen... Vielleicht noch Stateful-Inspection oder sowas, das IDS ist zumindest Mist, ... Darum wäre RPC-over-HTTPS gut: Auf deiner Seite kannst dann alles dicht machen ausser SSL. Ich werde das zumindest anbieten... vor allem weil OWA genutzt wird... aber dann noch sowas... da ist http auch offen mit einer Script-Weiterleitung auf https... :( also die Zeit hab ich tagsüber ein kleines "s" extra zu tippen. Gruß Zitieren Link zu diesem Kommentar
NorbertFe 1.809 Geschrieben 9. Mai 2008 Melden Teilen Geschrieben 9. Mai 2008 Ich habe nur grad ein Teil der DNS Zonen (auszugsweise) gesehen, das reicht schon :( Das fällt dann ja auch unter die Devise: ...denn sie wissen nicht, was sie tun. ;) Bye Norbert Zitieren Link zu diesem Kommentar
Shandurai 10 Geschrieben 13. Mai 2008 Autor Melden Teilen Geschrieben 13. Mai 2008 Danke euch beiden! Ich habe die Informationen weitergegeben und mal sehen, was bei raus kommt... wenn aber zu so einem frühen Zeitpunkt die ersten Zweifel an der "Dienstleisterlösung" (die zwar auch vom Rest der Welt eingesetzt wird) aufkommen, dann erwarte ich da leider nicht viel :-/ ...ich lass mich aber gerne belehren und hoffe, dass die gutgemeinte Beratung fruchtet. Grüße! Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.