Jump to content

franky Z

Members
  • Gesamte Inhalte

    29
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von franky Z

  1. Aus der Beschreibung des Backup-Scripts: "The backup disks are created as thin disks to save network bandwidth and the backup window". Es wird also auch nur der belegte Platz übertragen. Gesichert wird dabei auch nicht direkt auf Tape, sondern erst auf Disk.

    Was mich interessieren würde: macht der DP ein Imagebackup? Mit Backup Exec muss ich nach einem DR noch das AD, Exchange und SQL manuell wiederherstellen.

  2. @franky

    dann steht aber mein windows server, vielleicht nicht mit einem ganzen aber zumindest nem halben bein im netz. das wollt ich ja gerade verhindern.

    Das macht aber nur etwas wenn du das integrierte VPN für unsicherer hältst als das in einem Router. Das integrierte VPN hat Vorteile:

    - einfache Installation auf Server und Client

    - Verwaltung der Berechtigungen über AD

    - keine zusätzliche Clientsoftware

    - keine zusätzliche Benutzerverwaltung

    - kostet nix

  3. Du nimmst einfach den integrierten VPN-Server von Windows und nicht den von IPCOP. Oder du steigst um auf SBS2003, dann kannst du den "Remote Webarbeitsplatz" nutzen und brauchst überhaupt kein VPN einrichten. Damit kann man sich per Browser auf seinem Office-Computer remote anmelden. Da gibt es sogar ein Wake On Lan Tool dafür mit dem der Arbeitsplatzrechner remote gestartet werden kann.

     

    Wenn sich der Remote-Computer direkt an der Domäne anmelden soll kann er das mit "per DFÜ" im Anmeldebildschirm. Wenn der User sich per Remote-Desktop oder Remote Webarbeitsplatz an seinem Bürorechner anmeldet, greifen die GPOs natürlich auch und du hast bessere Performance und deine gewohnte Arbeitsumgebung.

  4. Sehr interessant. Allerdings gibt es wohl keine Möglichkeit sich mit Windows Boardmitteln mit dem VPN Server des IPCop zu verbinden.

    Das geht schon irgendwie, ist aber irre aufwändig. Nicht zu empfehlen.

    Die Idee mit der DMZ finde ich ja einleuchtend, aber wenn in der Firewall nur die Ports geöffnet werden, die auch benötigt werden, also sagen wir mal VPN, dann hätte ein Angreifer doch nur die Möglichkeit über diesen Port mein System zu kompromittieren.

    Ja genau, dito mit z.B. dem Mailserver, der im internen Netz direkt angesprochen wird. Ein Angriff setzt i.d.R. voraus, dass die Anwendung eine Sicherheitslücke hat oder schwache Passwörter.

    Wenn ich jetzt davon ausgehe, das der IPCop keine Sicherheitslücke hat und mein VPN Server korrekt konfiguriert wurde, dann sollte man das doch als sicher bezeichnen können

    Das derjenige, der sich per VPN verbindet, über seinen Client Müll ins Netz bringen kann ist klar.

    Genau das ist der Kritikpunkt, man hat die Kisten nicht so unter Kontrolle wie lokale Maschinen. Wenn das VPN aber nur einige User verwenden, kann man da IMHO schon ein Auge drauf haben.

    Wenn ich es am Wochenende zeitlich schaffe, werde ich mal auf einem alten Pentium II 233 MHz, 64 mb und 20gb platte den IPCop aufsetzen.

    Kann ich denn trotzdem den DHCP auf dem Windows Server laufen lassen? Oder muss ich zwingend den DHCP des Routers verwenden? Würde gerne auf dem Windows Server den RIS laufen lassen.

    Hardware ist OK solange kein Proxy aktiviert ist. DHCP sollte unbedingt auf dem Win Server bleiben (DHCP auf dem Router deaktiviert und Router als Default Gateway beim Windows DHCP eingetragen).

    Grüße,

    Frank

  5. Ich wollte es sowieso so machen, dass er auf seinem privat Rechner auf dem desktop einfach eine Verknüpfung bekommt, mit der sich die ERP-Software starten lässt.

    Wenn die Anwendung nur wenig Traffic benötigt geht das.

    Wenn er sich zusätzlich noch an die Domäne anmelden soll, dann mache ich das direkt im Anmeldebildschirm über dfü? Ist das korrekt? Dann bekommt der Rechner ne IP aus dem lokalen Firmennetz und verhält sich somit als würde er direkt am Switch im Büro hängen?

    Die IP aus dem Firmennetz bekommt er bei VPN immer (physikalische Verbindung). Mit der DFÜ-Option kann man sich dann direkt an der Domäne anmelden (logische Anmeldung, ist meistens nicht nötig). Wie du schon beschreibst, verhält sich der Client so als wenn er direkt am Switch hängen würde wenn der VPN-Endpunkt sich im Firmennetz befindet. Weil das natürlich ein gewisses Risiko ist, hat Johannes vorgeschlagen, die VPN Verbindung in einer RAS DMZ enden zu lassen (ausserhalb des Firmennetzwerks) und von da aus z.B. nur bestimmte Ports in das Firmennetzwerk freizuschalten. Konsequenterweise darf man dann aber auch keine Notebooks einfach ans Firmennetz anstöpseln, wenn sie von ausserhalb zurückkommen. Ich würde die erste Option nehmen (direkt ins Netz) und VPN mit Windows-Bordmitteln machen, allerdings sollten die Passwörter regelmässig geändert werden und einigermassen sicher sein, ausserdem sollte die Antivirussoftware auf den Clients die sich verbinden regelmässig gecheckt werden.

     

    Grüße,

    Frank

  6. Klingt ja ziemlich interessant. Wleche Anforderunge an die Hardware? Ich hab hier noch nen Haufen alter Kisten stehen. Kannst mir nochmal nen Tipp geben, wo ich mich informieren kann. Welche Distribution soll ich denn nehmen? Suse?

    Kann ich mich denn auch mit Windows Boardmitteln mit dem Teil verbinden?

    Homepage: IPCop.org :: The bad packets stop here!

    Eine Linux-Distribution braucht man dafür nicht, ist alles komplett. Du kannst dir unter Downloads die Datei "ipcop-1.4.16-install-cd.i386.iso" downladen, dann z.B. mit Nero ("Image brennen") das Image auf CD brennen. Dann einfach von der CD booten und den Installations-Anweisungen folgen.

    Unter "Documentation" findest du eigentlich alles, auch eine "Quick Start Guide". Ich würde einen alten PC ab 400MHz nehmen und eine Platte mit ca 20GB, es reicht aber auch weniger, und ja, die Konfiguration geht dann über Browser von Windows aus wie bei einem SOHO-Router. Tastatur und Monitor brauchst du an dem FW-Rechner nur bei der ersten Installation. Die Add-Ons werden auch über Browser installiert, wenn du ausgehende Verbindungen einschränken willst, brauchst du das BlockOutTraffic Add-On.

  7. Hi,

     

    das ist leider falsch. Die RDP Sessions bei Windows dürfen nur zu Support und Administration verwendet werden.

     

    Gruß

    So, hast du dafür auch eine Quelle? In der Hilfe zu Remotedesktop heißt es:

     

    Übersicht über Remotedesktop

    Remotedesktop unter Windows XP Professional ermöglicht Ihnen den Zugriff auf eine Windows-Sitzung, die auf Ihrem Computer ausgeführt wird, während Sie an einem anderen Computer arbeiten. Das bedeutet beispielsweise, dass Sie von zu Hause aus eine Verbindung zum Computer an Ihrer Arbeitsstelle herstellen können. Dadurch erhalten Sie Zugriff auf alle Anwendungen, Dateien und Netzwerkressourcen, so als ob Sie sich an Ihrem Computer im Büro befänden. Sie können an Ihrer Arbeitsstelle Programme geöffnet lassen. Wenn Sie nach Hause kommen, wird Ihr Desktop der Arbeitsstelle auf Ihrem Computer zu Hause angezeigt, und dieselben Programme sind geöffnet.

     

    und weiter:

     

    Remotedesktop ermöglicht eine Reihe von Szenarios, wie die Folgenden:

     

    Arbeiten zu Hause - Zugriff auf laufende Arbeiten auf Ihrem Computer im Büro von zu Hause aus, einschließlich uneingeschränktem Zugriff auf alle lokalen Geräte und alle Remotegeräte.

    Zusammenarbeit - Nehmen Sie Ihren Desktop mit ins Büro eines Kollegen, um Code zu debuggen, eine Microsoft PowerPoint-Diapräsentation zu aktualisieren, oder die Rechtschreibung eines Dokuments zu überprüfen.

     

    Von "nur zu Support und Administration" kann ich da nichts finden.

  8. Ich stelle mir das so vor, das der Chef sich von seinem privat Client per VPN Client ins Netz einwählt und dann an seinem standardmäßigen Desktop arbeiten kann, als würde er an seinem Schreibtisch sitzen.

    Macht man das dann per Remotedesktop? Alternativen?

    Ich komme darauf nochmal zurück weil das ein bisschen untergegangen ist denke ich. Das ist problemlos möglich und ist keine Lizenzverletzung, weil die Terminalsitzung ja nicht zum Server sondern direkt zum Client geht. TS-Lizenzen braucht man dafür nicht.

  9. Jetzt stellt sich mir die Frage, nach der Sicherheit. Hierzu würde ich gerne eure Meinungen hören. Im Moment denke ich, dass eine Hardwarefirewall genau das richtige wäre.

    Ich habe nur begrenzte Kenntnisse in Sachen Linux, sodass ich etwas selbstgebautes wie IPCOP nicht verwenden möchte.

    Auch wenn du das bereits ausgeschlossen hast, für IPCOP benötigst du NULL Linux Kenntnisse, die Konfiguration/Überwachung funktioniert ausschliesslich über das grafische Webinterface. Die Installation läuft auch über eine grafische Oberfläche und geht supereinfach. An der Kommandozeile muss man NICHTS machen. Mit dem BlockOutTraffic Add-On kannst du auch alle ausgehenden Verbindungen blocken und nur explizite Verbindungen nach draussen zulassen. Alles übersichtlich und einfach, kann mir nicht vorstellen, dass eine gekaufte Firewall einfacher zu konfigurieren ist.

  10. Hi,

     

    ich hab das ein paar mal gemacht mit der "neue Domäne" Methode. Neuen SBS installieren, Server konfigurieren, User anlegen, Exchange Daten mit Outlook exportieren, Files kopieren, Workstations zur neuen Domäne hinzufügen, Profile kopieren, Exchange Daten mit Outlook importieren. Da gibt's eine Menge zu beachten und viel zu tun. Das nächste Mal werde ich wohl die Swing-Methode von Jeff Middleton oder Backup und Restore ausprobieren, wobei ich die Swing-Methode vorziehen würde weil man keine Altlasten mitnimmt.

  11. Hallo,

    du kannst nur auf den beteiligten Mailservern den SMTP-Verkehr protokollieren. Dazu brauchst du natürlich Zugriff auf jeweils mindestens einen der gerade kommunizierenden Mailserver. Z.B. wenn du über Smarthost versendest: Das SMTP-Log deines Servers zum Debuggen der Kommunkation zwischen dir und Smarthost, und das SMTP-Log des Empfänger-Servers für die Zustellung vom Smarthost zum Emfänger.

×
×
  • Neu erstellen...