- Verbot von Computersicherheitswerkzeugen öffnet Bundestrojaner Tür und Tor - Worldwatcher, 26.05.2007, 06:44
- Nu mal halblang... - FOX-NEWS, 26.05.2007, 11:06
- nana, mit nem Portscan von außen findet man aber sehr schnell offene Ports. (o.Text) - igelei, 26.05.2007, 11:23
- Und inwieweit betrifft mich das? - FOX-NEWS, 26.05.2007, 11:32
- Ist richtig. Aber für einen Adnin ist es schon hilfreich, wenn er mal von...mkT - igelei, 26.05.2007, 11:45
- Und inwieweit betrifft mich das? - FOX-NEWS, 26.05.2007, 11:32
- Re: eben nicht - Jermak Timofejewitsch, 26.05.2007, 11:50
- Re: Nachtrag - Zitat des MdB-Abweichlers Tauss - Jermak Timofejewitsch, 26.05.2007, 12:17
- ohne Weiterentwicklung von Einbruchswerkzeugen ist keine Abwehr mehr möglich (o.Text) - ManfredF, 28.05.2007, 17:33
- nana, mit nem Portscan von außen findet man aber sehr schnell offene Ports. (o.Text) - igelei, 26.05.2007, 11:23
- ähm, wie wollen sie netstat -an denn verbieten?... mkT - igelei, 26.05.2007, 11:20
- Re: Verbot von Computersicherheitswerkzeugen öffnet Bundestrojaner Tür und Tor - Illuminati, 26.05.2007, 11:44
- Re: Verbot von Computersicherheitswerkzeugen öffnet Bundestrojaner Tür und Tor - FOX-NEWS, 26.05.2007, 13:32
- Re: Der Bundesschaeuble im Honeypot - Tassie Devil, 26.05.2007, 18:01
- Was ist die Lösung für den Hausgebrauch? - FOX-NEWS, 27.05.2007, 11:15
- Re: Was ist die Lösung für den Hausgebrauch? - Tassie Devil, 27.05.2007, 16:31
- Was ist die Lösung für den Hausgebrauch? - FOX-NEWS, 27.05.2007, 11:15
- Re: Der Bundesschaeuble im Honeypot - Tassie Devil, 26.05.2007, 18:01
- Re: Verbot von Computersicherheitswerkzeugen öffnet Bundestrojaner Tür und Tor - FOX-NEWS, 26.05.2007, 13:32
- Re: soll ich mich stellen? - Fremdwort, 26.05.2007, 13:07
- Nu mal halblang... - FOX-NEWS, 26.05.2007, 11:06
Re: Der Bundesschaeuble im Honeypot
-->>>wie wärs mit dem Virtual PC - für das normale Surfen, innerhalb des Virtual PC können sich die Schnüffler nach Herzenslust austoben - um es für diese Klientel noch etwas interessanter zu gestalten, kann man auf dem Virtual PC das Programm -TOR- installieren, damit kann über einen Proxy die IP-Adresse verändert werden.
>>So sind dann alle zufrieden - und jeder ist beschäftigt
>>Gruss
>Wenn man konsequent ist, ist das eine Lösung.
Hmm, Foxy, das kommt darauf an, was Du unter konsequent verstehst.
Ueberhaupt, dem MS Virtual PC oder Virtual Server wuerde ich jederzeit ein VMWare Produkt vorziehen, ich schoepfe auch aus inzwischen mehr als 27 Jahren Virtualisierung auf richtig grossen bis zu ganz kleinen Kisten meine Erfahrungen. ;-)
Aber ich sehe, ein paar von Euch Jungens denken schon mit. ;-)
>Aber dann muss das Hostsystem vom Netz abgekoppelt sein und die Netzwerkkarte exclusiv der VM zugeordnet sein.
Ich weiss, Foxy, was die Probleme sind, aber das ist nicht so gut, was Du da machst, weil dann die NIC nur 1 VM Guest dediziert ist, was zur Folge hat, dass sowohl dein Host-OP wie auch Deine Guest-OPs mit Ausnahme diesem 1 Guest-OP mit der dedizierten NIC netztechnisch leider nicht erreichbar sind, und das wiederum bedeutet, dass Du jede Menge Host-OP- und Guest-OP-Inseln hast, deren Administration in eigentlich jeder Beziehung einer Rallye Paris-Dakar zu Fuss entspricht.
>Auch darfts du der VM keinen Zugriff auf die Datenverzeichnisse des Hostsystems geben - alles muss dann über Transferverzeichnisse laufen.
Das ist richtig, aber auch die Maintenance der TXF-Verzeichnisse kann sich zu typischer Schwielen-Administration entwickeln und ausarten.
Tassie wuerde das Architektur-Problem auch durch Virtualisierung des Intranet-LAN wie folgt loesen:
1. Strenges Administrations-Regiment, um die Zuegel jederzeit managable auf allen Levels voll in der Hand zu halten, dadurch keinerlei"Hardware/Software-Auto-Update"-Funktionen eingeschaltet haben, alles off.
2. Die NIC eines jeden System-Nodes (PC, Server, Bladecenter etc.) ist real immer auf das Host-OP geschaltet, d.h. das Host-OP verwaltet die gesamten Hardware-Resourcen einschliesslich der NIC.
3. Die Host-OPs erhalten im 1-n Domain-LAN ihre eigene Virtual-IP-Address-Ranges gemaess den Spezifikationen fuer Class B und C Netzwerke (Class C z.B. 192.168.Host-VIPAXXX.y). Unter der Vorraussetzung, dass jede Virtual Subdomain nicht mehr als 254 IP-Adressen nutzen darf, wuerde ich den 3. Qualifier bei der IPv4-Address-Range (Host-VIPAXXX) mit 001 beginnen lassen und in Abhaengigkeit der Anzahl der zu administrierenden Host-OP-Gruppen grosszuegig nach oben abgerundet bei 010 enden lassen (Max. Anzahl der System-Nodes mit Host-OPs waeren damit 254 x 10 = 2540). Die Host-VIPAXXX-Range ist ausschliesslich fuer Intranet-LAN-Communication eingerichtet, es gibt keinerlei Router, Gateways oder sonstige Pfade innerhalb dieser Host-VIPAXXX-Range, die auf IP-Adressen ausserhalb verweisen oder von aussen nach IP-Adressen innerhalb verweisen, d.h. dass die Host-VIPAXXX-Range getrennt von anderen IP-Adress-Ranges innerhalb des Intranet-LANS wie auch von Pfaden ins/vom Internet voellig isoliert laeuft.
4. Die Guest-OPs erhalten im 1-n Domain-LAN ihre eigene Virtual-IP-Address-Ranges gemaess den Spezifikationen fuer Class B und C Netzwerke (Class C z.B. 192.168.Guest-VIPAXXX.y). Unter der Vorraussetzung, dass jede Virtual Subdomain nicht mehr als 254 IP-Adressen nutzen darf, wuerde ich den 3. Qualifier bei der IPv4-Address-Range (Guest-VIPAXXX) mit 011 beginnen lassen und in Abhaengigkeit der Anzahl der zu administrierenden Guest-OP-Gruppen grosszuegig nach oben abgerundet bei 030 enden lassen (Max. Anzahl der System-Nodes mit Guest-OPs waeren damit 254 x 20 = 5080). Die Guest-VIPAXXX-Range ist sowohl fuer ausschliessliche Intranet-LAN-Communication eingerichtet, hierfuer wuerde ich die Guest-VIPAXXX-Range 011-020 vorsehen, es gibt keinerlei Router, Gateways oder sonstige Pfade innerhalb dieser Guest-VIPAXXX-Range, die auf IP-Adressen ausserhalb verweisen oder von aussen nach IP-Adressen innerhalb verweisen, d.h. dass die Guest-VIPAXXX-Range 011-020 getrennt von anderen IP-Adress-Ranges innerhalb des Intranet-LANs wie auch von Pfaden ins/vom Internet voellig isoliert laeuft, wie auch fuer Intranet-LAN-Communication mit Zugriffen auf externe Netzwerke inklusiv dem Internet eingerichtet (ueber Router/Gateways), hierfuer wuerde ich die Guest-VIPAXXX-Range 021-030 vorsehen, diese letztere Guest-VIPAXXX-Range ist folglich ein nicht isoliertes"offenes" Intranet-LAN auch mit Zugriff aufs Internet und ggf. direkter Zugriff vom Internet ins Intranet-LAN.
5. Das Lifecycle-Management bei den Host-OPs wuerde ich so gestalten, dass ich in der Administrator-Developer-Kueche (ein paar Kisten mit ihren NICs und eigener ADMIN-VIPAXXX-Range z.B. 3. Qualifier 251-254 mit Zugriff auf Intranet-LAN und Verbindung ins Internet, der von aussen das Eindringen mit Firewall, Proxy und weiteren Abdichtungen verriegelt und verrammelt ist) die Host-OPs als Gruppenmodelle hochziehen wuerde, um sie dann gruppenweise in der Host-VIPAXXX-Address-Range Intranet-LAN distributed zum Einsatz zu bringen (entweder auf jedem System-Node per Flip-Flop HD-Boot-Partition, um die jeweils vorherige Version des Host-OPs als Fallback booten zu koennen, oder im Falle des Netboots der System-Nodes dasselbe Flip-Flop HD-Boot-Verfahren auf dem Gruppen-Boot-Server.
6. Das Lifecycle-Management bei den Guest-OPs wuerde ich so gestalten, dass ich in der Administrator-Developer-Kueche die Guest-OPs nach Nutzungsaspekten (z.B. 1 MS Office System Node Modell, 1 Internet Access System Node Modell, 1 MS Sharepoint System Node Modell usw. usf.) als Gruppenmodelle hochziehen wuerde, um sie dann gruppenweise in der Guest-VIPAXXX-Address-Range Intranet-LAN distributed zum Einsatz zu bringen, dabei wuerde ich die Management-Funktionen der Host-OPs fuer die Distribution der Guest-OPs weidlich nutzen.
Was meinst Du bis hierher mal zu dieser Architektur, Foxy?
>Gruss
Gruss!
TD

gesamter Thread: