Jump to content

gardsen

Members
  • Gesamte Inhalte

    68
  • Registriert seit

  • Letzter Besuch

Über gardsen

  • Geburtstag 26.10.1985

Profile Fields

  • Member Title
    Newbie

Fortschritt von gardsen

Fellow

Fellow (7/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Ich verschließe mich nicht den technischen Gegebenheiten. Ich habe weitere Fragen gestellt, die mir nicht beantwortet wurden, über eine Lösung, die mir praktikabel erschien. Wir gewinnen dadurch an Sicherheit, punktum. Es ist eine Sache, ob ich einem Haufen Terminalserver den Zugriff auf ein System mit Freifahrt gewähre, oder einem. Risiko minimiert - darum geht's. Ich hab zuletzt gar nicht mehr davon gesprochen das trennen zu wollen, sondern einen anderen Weg zu beschreiten, der funktionieren müsste und auch supported ist. Auch ich mache das lange genug, um zu wissen, dass es nicht nur immer Schema F sein muss, sondern auch noch andere Wege gibt. Diese Suche ich nunmal. Und da kann ich es (wie gesagt mal wieder) nicht verstehen, dass man hier auf komische Art und Weise von Grund auf kritisiert und sogar angemacht wird, dass man Lösungen sucht. Der Ton macht dann doch die Musik und den finde ich etwas daneben.
  2. Steht alles in den Beiträgen drin. Ich habe selbst die Frage gestellt, ob ab 2016 eine Trennung möglich ist, was wohl bedeutet, dass ich es nicht weiß und gerne wissen möchte. Aus den Kryptografie- und Firewallrichtlinien des BSI lässt sich das alles ganz wunderbar ableiten, muss man nur lesen. Übrigens: Wenn du "paar" User schreibst, ist das, als wenn ich viel auf deine "paar" MVP-Titel geben würde. Wie kommt das beim Lesen an? Nicht so gut oder?
  3. Habe ich. Aber auch das ist hier so eine Unart, nur das lesen zu wollen, was man lesen möchte. Und: die "anderswo" gucken auch gerne mal über den Tellerrand und geben sich Mühe und beten nicht nur Technet-Artikel hoch und runter. Ist mir übrigens neu, dass man weniger wert ist, wenn man nur eine bestimmte Userzahl hat. Aber auch da wieder nicht weiter verwunderlich. Tschüß.
  4. Schön, dass man hier mal wieder polarisiert. Ich danke Euch für diese Bestätigung. Könnt das Thema zumachen. Ich finde das immer wieder sagenhaft hier... Das hat mit neurotisch nichts zu tun, man sollte nur nicht einfach immer alle Dienste in ein Netzsegment hauen, nur weil's praktisch ist. Wir reden hier über 3000 User und wir haben diese Produkte im Einsatz, sind über weit mehr als 240 Standorte verteilt. Wo es unsicher wird? Genau da. Ist aber auch egal, ich werde mich anderswo informieren...
  5. Mir knackt jemand das Netz auf und landet auf meinem HTCAS, der steht im gleichen Segment wie mein Mailboxserver. Durch meine PaloAlto kann ich jetzt nichts mehr sehen, da die nur Segmentübergreifend arbeitet. Auch ein NetScaler schafft es nicht, mit der AAA-Filterung die ungewollten Änderungen und / oder Angriffe zu erkennen, weil auch hier keine Filterung auf Events möglich ist. Das ist mehr Sicherheit. Fakt ist, dass das BSI und eigentlich jedes gute Firewallkonzept genau diese Dinge vorgibt, besonders schützenswerte Daten (Mailboxdaten, Mails(!)) nicht in die gleichen Schutzzonen zu packen, wie Zugriffsserver. Steht hier: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/baust/b01/b01007.html und hier: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/baust/b03/b03301.html
  6. Ja, (noch, bis zur Umstellung in ca 2? Jahren) Exchange '07. Und nein, genau darum geht es hier doch. Da sehe ich jetzt (die Seite hatte ich auch schon zu fassen) in "Figure 4" genau die Konfiguration wie sie auch bei uns sein soll. Nur, dass der Hub/Transport noch mit als Rolle auf dem CAS läuft (das ist auch jetzt schon so, ändert aber auch nichts). Die entsprechende Regel kann man schaffen. Und automatisch habe ich ein deutlich höheres Maß an Sicherheit reingepackt. Für die Clients kann ich dann die in der Zeichnung genannten Ports verwenden und ich habe genau die Lösung.
  7. Weil in der Datenbank die Daten liegen. Unsere SQL-Server liegen im gleichen Netzsegment, da gehören Sie auch hin. Sollte es tatsächlich mal jemandem gelingen, in das Tunnelnetzwerk einzubrechen, müsste der erstmal auf den HTCAS, der wiederum hat nur die entsprechenden Ports zum Datenbankserver geöffnet. Das ist einfach eine Sicherheitsbarriere, die zusätzlich eingebaut werden soll und muss. Den Blog habe ich gelesen, ja - getagged ist das aber auf Exchange 2007, daher dachte ich, das gilt auch dafür. Dann müssen wir uns wohl oder übel an das Thema CAS-Proxy ranmachen. Ich war nur davon ausgegangen, dass MS hier vielleicht (ja ab 2016?) dem Kunden überlässt, wo er die Server hinstellt. Hm. Naja nein, das wirft eher weiterhin die Frage auf: Ich brauche zwingend einen CAS im gleichen Segment / Site für den Mailboxserver. Ok, kann ich machen. Ich verstehe das aber so, dass ich auch einen CAS ohne Mailboxserver (also genau andersrum) bauen kann, der wiederum geht dann gegen den Mailboxserver...? Jetzt bin ich endgültig verwirrt.
  8. Das gilt aber "nur" für Exchange '07 oder? Ab höheren Versionen ist doch eine Trennung möglich oder nicht? Nun, der Sicherheitsgedanke steht im Vordergund. Wir haben ein Stern-VPN, wo alle Tunnel und Services in einem Segment terminieren. Die Datenbankserver wollen wir (da besonders schützenswert) in ein Segment "dahinter" heben. Dieses Segment ist nicht aus den Tunneln erreichbar. Dann kann ich das gedanklich abhaken. Danke für die Hilfe!
  9. Hey! mit 2007 deshalb, weil der Umstieg auf 2016 mit CALs etc. noch nicht budgetiert ist. Es ist ja keine echte DMZ, deshalb die ". Es ist einfach nur ein anderes FW-Segment, wo auch AD-Memberserver ganz normal drinstehen. Ein Zugriff über WAN ist hier nicht möglich. Die EDGE-Systeme stehen in der DMZ ja. Gruß, Gardsen
  10. Hallo zusammen, hier steht, dass es nicht supported ist, einen HT / CAS hinter einer Firewall zu betreiben, bzw. den Rollenserver in ein anderes Netzsegment mit einer Firewall zu installieren. Was ist nun aber in dem Fall, in dem der entsprechende Server bidirektional (voll IP) durch die FW mit den Mailboxservern sprechen darf, ist dann noch eine supportete Umgebung vorhanden? Schematisch wäre das so: Segment 1 (Sitename: SITE-1) Mailbox-Server 1+2, DC1 Segment 2 (Sitename: SITE-2) Hub Transport, Client Access, DC2 Edge lasse ich außen vor, das ist in diesem Fall "egal". DC1 und DC2 synchronisieren sich natürlich (keine RODCs) und die Mailbox-Server können mit HT/CAS wie beschrieben kommunizieren. "Darf" man das so? Grüße, Gardsen
  11. Hallo zusammen, wir machen uns gerade daran, den ersten RODC (2008 R2) in Betrieb zu nehmen. Forest- und Domainlevel, sowie adprep /rodcprep sind bereits erledigt. Die Konstellation sieht so aus: DC1 <-|-> DC2 <-|-> DC3 DC3 soll RODC werden, darf durch die Firewall ( | ) mit DC2, aber nicht mit dem RID-Master DC1 sprechen. Nun bekomme ich logischer Weise den Fehler "Derzeit kann kein beschreibbarer.....da der RID-Master "DC1" offline ist". Kann ich das nur lösen, indem die Firewall für die Erstsynchronisation für die Verbindung DC1 <-|-> DC3 freigeschaltet wird, die Replikation erfolgt und als Partner später dann DC2 eingetragen wird (und logischer Weise die FW wieder aktiviert wird)? Gibt es einen alternativen Weg? Viele Grüße, Gardsen
  12. Vertippt.... es war natürlich DHCPServerlog nicht DNS. Ja, Wireshark anzuwerfen klingt immer so einfach - für mich ist dieses Tool nach wie vor ein ziemliches Monster, mit dem ich mich intensiver beschäftigen müsste. Leider sind solche Probleme in unserem Bereich zu selten, als dass sich das lohnen würde...glücklicher Weise :)
  13. Es hat geklappt. Thread kann m.E. geschlossen werden. Vielen Dank für die Denkanstöße an alle!
  14. So, nachdem ich ja doch intensiv an mir gezweifelt hatte, hier die Auflösung - das wird kein Mensch in seinem Netzwerk nachbauen :) Wir haben zwei NetApp-Systeme, die sich replizieren müssen. Da wir den Replikationstraffic nicht über die ASA schieben können (nur 100Mbit-Schnittstelle), haben wir auf unserer GigaBit - Strecke über Layer2 VRF geroutet. Klingt etwas wild, ist es auch, funktioniert aber. Der entsprechende Switch wiederum meinte jetzt, er müsse arp-proxy spielen. Tolle Sache! Mit einer entsprechenden Option konnte dies nun ausgeschaltet werden und die Systeme schmeißen sich die ARP-Table nicht mehr voll.... Es ist also hausgemachtes Leid gewesen, ich teste das heute abend noch mal und werde dann hoffentlich einen Erfolg melden ;)
  15. Ich habe unsere Netzwerker ja schon gefragt, jetzt kann ich das eben belegen. Normaler Weise sind diese Dinge auch abgestellt, kann sein, dass er sich da geirrt hat...
×
×
  • Neu erstellen...