5
Laufwerk mappen von oder zu Servern in Hinsicht auf Security und Best Practice
Gibt es allgemeine Abfassungen oder Aussagen zu Securitybedenken oder -guidelines und BestPractice zum Thema Laufwerksmapping von oder zu Servern ?
Hallo,
manche von euch werden sich ueber meine Frage wundern, darum hier kurz die Vorgeschichte.
Ich bin Application Support Specialist und unterstuetze von I&TS Seite einen Fachbereich bei der Implementierung eines neuen Projektes, das unter anderem einen Application Server beinhaltet. Eine Anforderung aus dem Fachbereich ist ein Laufwerk vom Application Server zu einem Fileserver (beide abgesichertes Intranet) zu mappen um mit einer Applikationsfunktion Daten auf "unmanaged disc" (was das gemappte Laufwerk waere) zu speichern. Von I&TS Seite wurde ich nun aufgeklaert, dass das mappen von Laufwerken von und zu Servern gegen Security und Best Practice verstoesst. Da mein Projekt hier nun offensichtlich dazu herhalten muss, diese im Moment noch ungeschriebene Guideline in der Firma herzustellen habe ich die Aufgabe herauszufinden, welche Bedenken in Sachen Security and BestPractice hier bestehen und ob es dazu evtl. Abfassungen etc. gibt. Ich muss dazu sagen, dass es hier zwar eine Securityabteilung gibt, diese aber nicht fuer das Nachforschen solcher Themen zustaendig ist, sondern nur sichtet und bewertet, was ich dann um die Ecke bringe....
.... Auch wurden hier bei vergangenen Audits schon gemappte Laufwerke als kritisch bewertet. Leider gibt es auch aus der Audit Ecke keine Dokumentationen, warum kritisch...... (Lustig und ich kann euch sagen, ich arbeite nicht in Deutschland 
)
Gibt es allgemeine Abfassungen oder Aussagen zu Securitybedenken oder -guidelines und BestPractice zum Thema Laufwerksmapping von oder zu Servern ?
Bin fuer jeden Tip oder Hilfe dazu dankbar
Gruesse
GhostGumTree
manche von euch werden sich ueber meine Frage wundern, darum hier kurz die Vorgeschichte.
Ich bin Application Support Specialist und unterstuetze von I&TS Seite einen Fachbereich bei der Implementierung eines neuen Projektes, das unter anderem einen Application Server beinhaltet. Eine Anforderung aus dem Fachbereich ist ein Laufwerk vom Application Server zu einem Fileserver (beide abgesichertes Intranet) zu mappen um mit einer Applikationsfunktion Daten auf "unmanaged disc" (was das gemappte Laufwerk waere) zu speichern. Von I&TS Seite wurde ich nun aufgeklaert, dass das mappen von Laufwerken von und zu Servern gegen Security und Best Practice verstoesst. Da mein Projekt hier nun offensichtlich dazu herhalten muss, diese im Moment noch ungeschriebene Guideline in der Firma herzustellen habe ich die Aufgabe herauszufinden, welche Bedenken in Sachen Security and BestPractice hier bestehen und ob es dazu evtl. Abfassungen etc. gibt. Ich muss dazu sagen, dass es hier zwar eine Securityabteilung gibt, diese aber nicht fuer das Nachforschen solcher Themen zustaendig ist, sondern nur sichtet und bewertet, was ich dann um die Ecke bringe....
.... Auch wurden hier bei vergangenen Audits schon gemappte Laufwerke als kritisch bewertet. Leider gibt es auch aus der Audit Ecke keine Dokumentationen, warum kritisch...... (Lustig und ich kann euch sagen, ich arbeite nicht in Deutschland )Gibt es allgemeine Abfassungen oder Aussagen zu Securitybedenken oder -guidelines und BestPractice zum Thema Laufwerksmapping von oder zu Servern ?
Bin fuer jeden Tip oder Hilfe dazu dankbar
Gruesse
GhostGumTree
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 54592
Url: https://administrator.de/contentid/54592
Printed on: April 16, 2024 at 22:04 o'clock
5 Comments
Latest comment
Äh - arbeitest du zufällig in Albanien? (kleiner Scherz).
Kommt mir alles rech komisch vor.
Um Daten von einem System auf ein anderes zu schaufeln, muss man eben irgendwie eine Verbindung herstellen zwischen beiden, und ein Protokoll verwenden, mit dem beide Systeme sich "unerhalten" können.
Für Datenübertragungen wären denkbar FTP, SFTP, SCP, Telnet, DFS, SMB, NFS, HTTP, HTTPS und wohl noch einige Protokolle mehr.
Was kann sicherheitstechnisch passieren?
1. Die Daten könnten gesnifft werden
Daher eine verschlüsselte Datenübertragung wählen. Die Systeme könnten über eine extra Netzwerkkarte auch in einem eigenen speziellen Subnetz oder VLAN stecken in dem sie ihre Daten austauschen, auf das kein User oder "Angreifer" Zugriff hätte. Oder aber ein dediziertes Netzkabel von System 1 zu System 2, wenn NUR diese beiden Rechner Daten austauschen sollen.
2. Man-in-the-middle-attacke
Dazu könnte man statische MAC-Einträge auf den Rechnern machen, um dies auszuschliessen (ARP Poisoning verhindern).
3. Die Rechner könnten gehackt werden
Dagegen die Maschinen up-to-date halten und eventuell lokale Firewalls benutzen, oder auch Nessus/nmap/metasploit scans machen um den Sicherheitsstatus zu überprüfen
Antivirus/Antispyware verwenden um Trojaner/Keylogger abzuwehren. Oder am besten garnicht damit surfen u. nix installieren was man nicht wirklich braucht. Keine Dienste laufen lassen die man braucht (und diese auch nicht installieren wenn man sie nicht braucht).
4. Berechtigungen auf dem Filesystem
NTFS beispielsweise verwenden, und genau definieren, wer auf welche Daten welche Reche hat.
5. Authentisierung
Damit jemand, der Zugriff haben soll, sich sicher authentisiert, sollte man Passwortrichtlinien verwenden u. erzwingen, oder aber per Smartcard, biometrischer Lösungen oder Tokens die Authentisierung absichern - je nach Grad der Paranoia, versteht sich.
6. Physikalischer Zugang zum System
Die Systeme sollten in verschlossenen Räumen betrieben werden, da bei lokalem Zugriff ein Angreifer mit den Geräten eh machen könnte was er wollte.
Prinipiell gibt es Netzwerke nunmal, damit man Daten von Rechner A zu Rechner B oder auch C schaufeln kann. Wenn man zu starke Paranoia hat kann man freilich auch nen Praktikaten einstellen, der per USB Stick die Daten durch die Firma schleppt
Dieser sollte jedoch nonstop per Videokamera und/oder Gedankenkontrolle überprüft werden, ob er denn auch nix schlimmes mit dem USB STick anfängt (z. B. rektal).
Kommt mir alles rech komisch vor.
Um Daten von einem System auf ein anderes zu schaufeln, muss man eben irgendwie eine Verbindung herstellen zwischen beiden, und ein Protokoll verwenden, mit dem beide Systeme sich "unerhalten" können.
Für Datenübertragungen wären denkbar FTP, SFTP, SCP, Telnet, DFS, SMB, NFS, HTTP, HTTPS und wohl noch einige Protokolle mehr.
Was kann sicherheitstechnisch passieren?
1. Die Daten könnten gesnifft werden
Daher eine verschlüsselte Datenübertragung wählen. Die Systeme könnten über eine extra Netzwerkkarte auch in einem eigenen speziellen Subnetz oder VLAN stecken in dem sie ihre Daten austauschen, auf das kein User oder "Angreifer" Zugriff hätte. Oder aber ein dediziertes Netzkabel von System 1 zu System 2, wenn NUR diese beiden Rechner Daten austauschen sollen.
2. Man-in-the-middle-attacke
Dazu könnte man statische MAC-Einträge auf den Rechnern machen, um dies auszuschliessen (ARP Poisoning verhindern).
3. Die Rechner könnten gehackt werden
Dagegen die Maschinen up-to-date halten und eventuell lokale Firewalls benutzen, oder auch Nessus/nmap/metasploit scans machen um den Sicherheitsstatus zu überprüfen
Antivirus/Antispyware verwenden um Trojaner/Keylogger abzuwehren. Oder am besten garnicht damit surfen u. nix installieren was man nicht wirklich braucht. Keine Dienste laufen lassen die man braucht (und diese auch nicht installieren wenn man sie nicht braucht).
4. Berechtigungen auf dem Filesystem
NTFS beispielsweise verwenden, und genau definieren, wer auf welche Daten welche Reche hat.
5. Authentisierung
Damit jemand, der Zugriff haben soll, sich sicher authentisiert, sollte man Passwortrichtlinien verwenden u. erzwingen, oder aber per Smartcard, biometrischer Lösungen oder Tokens die Authentisierung absichern - je nach Grad der Paranoia, versteht sich.
6. Physikalischer Zugang zum System
Die Systeme sollten in verschlossenen Räumen betrieben werden, da bei lokalem Zugriff ein Angreifer mit den Geräten eh machen könnte was er wollte.
Prinipiell gibt es Netzwerke nunmal, damit man Daten von Rechner A zu Rechner B oder auch C schaufeln kann. Wenn man zu starke Paranoia hat kann man freilich auch nen Praktikaten einstellen, der per USB Stick die Daten durch die Firma schleppt
Dieser sollte jedoch nonstop per Videokamera und/oder Gedankenkontrolle überprüft werden, ob er denn auch nix schlimmes mit dem USB STick anfängt (z. B. rektal).
Hi,
danke fuer deine ausfuehrliche Antwort.
Es ist nicht Albanien. Eigentlich bin ich hier in einem Land von dem ich in Sachen Technologie und IT mehr erwartet haette und auch die Firma ist eigentlich keine Firma sondern die Regierung..... ist mein Ernst.......
Ich selber arbeite hier seit 6 Wochen und hab genau das Problem, dass ich in der Beziehung meine "Kollegen" von der IT nicht verstehe, was deren Problem mit dem Drive Mapping ist. Aber als braver Projektmitarbeiter vertrete ich natuerlich die Interessen der IT und versuche mit dem Thema weiterzukommen. Aber ich seh schon, dass ich hier und auch anderswo im Endeffekt nur meine persoenliche Meinung bestaetigt bekomme. Das Mappen von Laufwerken ist eine uebliche Sache. Ich bin mir nur nach wie vor nicht sicher, ob es keine allgemeinen Empfehlungen gibt in Sachen BestPractice, eben kein Laufwerk zu mappen. Die Application selber wuerde als Alternative eben noch den FTP oder oder SMTP anbieten. SCP oder SFTP waere natuerlich die Loesung aller Probleme, da verschluesselt, aber das kann die Software leider nicht.
Mal andersherum gefragt. Wenn du ein Laufwerkmapping vermeiden willst, welche Gruende wuerdest angeben ? Sender und Empfaenger stehen beide im abgesicherten Intranet.
Eine Antwort hierauf von einem der Obergurus in der hiesigen I&TS: "We don't want to open pipes to or from the server".... Diese Antwort hat mich wieder daran erinnert, dass der Security manchner Firmen am liebsten waere, dass alle Server am besten ohne jede connection, irgendwo eingesperrt werden und der Schluessel wird weggeworfen. Am besten sollten sie auch nicht angeschalten werden und wenn muesste der Strom von einem Hamster im Rad neben dem Server kommen. Was wieder nicht geht, da keiner hinkann um das Tier zu fuettern.......
P.S: Den USB Stick koennen wir glaub ich als Alternative ausschliessen, weil man fuer die Arbeit keinen Mitarbeiter findet (wer will schon den ganzen Tag mit einem USB-Stick im Hintern rumlaufen)........
danke fuer deine ausfuehrliche Antwort.
Es ist nicht Albanien. Eigentlich bin ich hier in einem Land von dem ich in Sachen Technologie und IT mehr erwartet haette und auch die Firma ist eigentlich keine Firma sondern die Regierung..... ist mein Ernst.......Ich selber arbeite hier seit 6 Wochen und hab genau das Problem, dass ich in der Beziehung meine "Kollegen" von der IT nicht verstehe, was deren Problem mit dem Drive Mapping ist. Aber als braver Projektmitarbeiter vertrete ich natuerlich die Interessen der IT und versuche mit dem Thema weiterzukommen. Aber ich seh schon, dass ich hier und auch anderswo im Endeffekt nur meine persoenliche Meinung bestaetigt bekomme. Das Mappen von Laufwerken ist eine uebliche Sache. Ich bin mir nur nach wie vor nicht sicher, ob es keine allgemeinen Empfehlungen gibt in Sachen BestPractice, eben kein Laufwerk zu mappen. Die Application selber wuerde als Alternative eben noch den FTP oder oder SMTP anbieten. SCP oder SFTP waere natuerlich die Loesung aller Probleme, da verschluesselt, aber das kann die Software leider nicht.
Mal andersherum gefragt. Wenn du ein Laufwerkmapping vermeiden willst, welche Gruende wuerdest angeben ? Sender und Empfaenger stehen beide im abgesicherten Intranet.
Eine Antwort hierauf von einem der Obergurus in der hiesigen I&TS: "We don't want to open pipes to or from the server".... Diese Antwort hat mich wieder daran erinnert, dass der Security manchner Firmen am liebsten waere, dass alle Server am besten ohne jede connection, irgendwo eingesperrt werden und der Schluessel wird weggeworfen. Am besten sollten sie auch nicht angeschalten werden und wenn muesste der Strom von einem Hamster im Rad neben dem Server kommen. Was wieder nicht geht, da keiner hinkann um das Tier zu fuettern.......
P.S: Den USB Stick koennen wir glaub ich als Alternative ausschliessen, weil man fuer die Arbeit keinen Mitarbeiter findet (wer will schon den ganzen Tag mit einem USB-Stick im Hintern rumlaufen)........
Naja, auch im "sicheren" Intranet ists meist nicht sooo sicher wie man denkt.
Die meisten Angriffe bzw Spielereien kommen von innen, zb. von gelangweilten Mitarbeitern oder Praktikanten oder auch Gästen.
Mittels der ARP Tricks kann man wie gesagt locker den Verkehr zw. zwei Rechnern mitschneiden, zb. kann RechnerC mitsniffen (auch im geswitchten Netz) was RechnerA zu RechnerB sendet, wenn er entsprechende Tools einsetzt (die frei verfügbar sind u. relativ einfach zu bedienen). Der Angreifer muss jedoch freilich im lokalen Subnetz sein, sonst geht mit ARP Poisoning garnix.
Wenn man nun ein unverschlüsseltes Protokoll nutzt (unverschl. emails, ftp, telnet) dann ist die Sicherheit freilich keinen Pfennig wert, unter "profesionellen" Massstäben.
Ein Laufwerkszugriff über kerberos Auth. auf DFS Laufwerke (Microsaft Domänen) usw ist aber verschlüsselt. SCP ist verschlüsselt. Da wird ein Angreifer wohl eher versuchen einen Keylogger auf dem Client unterzubringen (zb. per Emailanhang) um an das Passwort dranzukommen, als zu versuchen eine Verschlüsselung zu knacken (was zwar auch machbar ist, aber zu lange dauert bei starker Verschlüsselung. (Starke Verschlüsselung wäre AES ab 512bit oder 3DES. Schwach bis unbrauchbar wäre nach derzeitigem Stand DES oder RC4).
Ansonsten bleibt als einzige Lösung für deine Situation wohl der Einsatz von Terminaldiensten, zb. Citrix.
Deine Auftraggeber haben vielleicht auch Angst, dass sensitive Daten von Usern geklaut oder kopiert werden können - das kann man mit TerminalService Lösungen unterbinden, da der User nur mit dem Terminalserver per ICA Protokoll verbunden ist und kein eigentlicher Datei-download auf den Client stattfinden kann bei entsprechender Konfiguration. Auch Screenshots von Dateninhalten könnte man verhindern, da bliebe nur noch abfotografieren oder abtippen.
Dabei sollte das Serverzertifikat des Terminalservers von einer vertrauenwürdigen CA signiert werden, da auch eine verschlüsselte WEB-Session ohne Probleme gefaket werden kann, und der User ein gefälschtes Zertifikat nicht von einem "echten, aber fehlerhaften, da nicht signierten" Zertifikat unterscheiden kann. Im Grunde kann der User ja nix von nix unterscheiden, ausser vielleicht grosse Brüste von kleinen.
Die meisten Angriffe bzw Spielereien kommen von innen, zb. von gelangweilten Mitarbeitern oder Praktikanten oder auch Gästen.
Mittels der ARP Tricks kann man wie gesagt locker den Verkehr zw. zwei Rechnern mitschneiden, zb. kann RechnerC mitsniffen (auch im geswitchten Netz) was RechnerA zu RechnerB sendet, wenn er entsprechende Tools einsetzt (die frei verfügbar sind u. relativ einfach zu bedienen). Der Angreifer muss jedoch freilich im lokalen Subnetz sein, sonst geht mit ARP Poisoning garnix.
Wenn man nun ein unverschlüsseltes Protokoll nutzt (unverschl. emails, ftp, telnet) dann ist die Sicherheit freilich keinen Pfennig wert, unter "profesionellen" Massstäben.
Ein Laufwerkszugriff über kerberos Auth. auf DFS Laufwerke (Microsaft Domänen) usw ist aber verschlüsselt. SCP ist verschlüsselt. Da wird ein Angreifer wohl eher versuchen einen Keylogger auf dem Client unterzubringen (zb. per Emailanhang) um an das Passwort dranzukommen, als zu versuchen eine Verschlüsselung zu knacken (was zwar auch machbar ist, aber zu lange dauert bei starker Verschlüsselung. (Starke Verschlüsselung wäre AES ab 512bit oder 3DES. Schwach bis unbrauchbar wäre nach derzeitigem Stand DES oder RC4).
Ansonsten bleibt als einzige Lösung für deine Situation wohl der Einsatz von Terminaldiensten, zb. Citrix.
Deine Auftraggeber haben vielleicht auch Angst, dass sensitive Daten von Usern geklaut oder kopiert werden können - das kann man mit TerminalService Lösungen unterbinden, da der User nur mit dem Terminalserver per ICA Protokoll verbunden ist und kein eigentlicher Datei-download auf den Client stattfinden kann bei entsprechender Konfiguration. Auch Screenshots von Dateninhalten könnte man verhindern, da bliebe nur noch abfotografieren oder abtippen.
Dabei sollte das Serverzertifikat des Terminalservers von einer vertrauenwürdigen CA signiert werden, da auch eine verschlüsselte WEB-Session ohne Probleme gefaket werden kann, und der User ein gefälschtes Zertifikat nicht von einem "echten, aber fehlerhaften, da nicht signierten" Zertifikat unterscheiden kann. Im Grunde kann der User ja nix von nix unterscheiden, ausser vielleicht grosse Brüste von kleinen.
Hallo,
du wirst lachen, aber ich habe die letzten Tage herausgefunden, dass es hier mehr um den Support von gemappten Laufwerken geht, als um die Security. Und wie ich schon befuerchtet habe, muss "mein" Projekt leider dafuer herhalten um alle undokumentierten neuen Richtlinien umzusetzen...... Aus den Infos, die du mir gegeben hast, hab ich ein I&TS Assessment gebastelt, dass gerade beim Securtiy- und Architectmanager zum Review vorliegt und aus dem (hoffentlich) eine Richtlinie innerhalb der Firma erstellt wird (damit beim naechsten Projekt kein ITler den gleichen Schmarrn nochmal machen muss...). Ich poste hier mal den Text, falls jemand mal vor dem gleichen Problem steht und was zusammenschreibseln muss:
2. I&TS Assessment “Drive Mapping”
2.1 Security
Regarding in keeping the XXX network concise I&TS will keep the amount of drive mappings as low as possible. Mapping drives criss-cross through a network makes it vulnerable against issues like for example
- Data sniffing
- Man-in-the-middle-attack
-Server Hack (if the server is hacked, the hacker would be able to expand the hack to other sources via mapped drives)
- Viruses, Worms, Exploits etc. could be spread from the infected server to other system via mapped drives
2.2 Development & Maintenance
To avoid the described security issues and to make sure, the drive mapping is high available a lot of development and maintenance is necessary. Following some examples of the necessary To-Dos:
- Development and implementation of an intelligent Auto-Map routine, which remaps the drive in case of server failures (both sides), connection problems etc. to assure the mapping is high available.
- Depending on the data criticality it is necessary to provide a way of data encryption which en- and decrypt the data.
- Creating and configure mapping user and password
2.3 Support
The fact that are two different system environments XXXXXXXXX are connected and the points described in 2.1 and 2.2 are increasing the complexity which brings a higher effort of support need mostly disproportional to the value.
2.4 Best Practice
Regarding the necessary security, maintenance and support the mapping of drives to or from servers is rated as: NOT BEST PRACTISE
Danke dir fuer deine Tips.
Gruesse
GhostGumTree
du wirst lachen, aber ich habe die letzten Tage herausgefunden, dass es hier mehr um den Support von gemappten Laufwerken geht, als um die Security. Und wie ich schon befuerchtet habe, muss "mein" Projekt leider dafuer herhalten um alle undokumentierten neuen Richtlinien umzusetzen...... Aus den Infos, die du mir gegeben hast, hab ich ein I&TS Assessment gebastelt, dass gerade beim Securtiy- und Architectmanager zum Review vorliegt und aus dem (hoffentlich) eine Richtlinie innerhalb der Firma erstellt wird (damit beim naechsten Projekt kein ITler den gleichen Schmarrn nochmal machen muss...). Ich poste hier mal den Text, falls jemand mal vor dem gleichen Problem steht und was zusammenschreibseln muss:
2. I&TS Assessment “Drive Mapping”
2.1 Security
Regarding in keeping the XXX network concise I&TS will keep the amount of drive mappings as low as possible. Mapping drives criss-cross through a network makes it vulnerable against issues like for example
- Data sniffing
- Man-in-the-middle-attack
-Server Hack (if the server is hacked, the hacker would be able to expand the hack to other sources via mapped drives)
- Viruses, Worms, Exploits etc. could be spread from the infected server to other system via mapped drives
2.2 Development & Maintenance
To avoid the described security issues and to make sure, the drive mapping is high available a lot of development and maintenance is necessary. Following some examples of the necessary To-Dos:
- Development and implementation of an intelligent Auto-Map routine, which remaps the drive in case of server failures (both sides), connection problems etc. to assure the mapping is high available.
- Depending on the data criticality it is necessary to provide a way of data encryption which en- and decrypt the data.
- Creating and configure mapping user and password
2.3 Support
The fact that are two different system environments XXXXXXXXX are connected and the points described in 2.1 and 2.2 are increasing the complexity which brings a higher effort of support need mostly disproportional to the value.
2.4 Best Practice
Regarding the necessary security, maintenance and support the mapping of drives to or from servers is rated as: NOT BEST PRACTISE
Danke dir fuer deine Tips.
Gruesse
GhostGumTree
Was heisst Support - das ist doch das A und O im Profi Umfeld, Netzlaufwerke zu benutzen und Daten nicht lokal zu halten. Zentrales Berechtigungs- und Backupkonzept ist ja nun wirklich nix "exotisches".
Weiss ja nicht was das für ein laden ist, aber wenn man sich da um den "Support" von gemappten laufwerken Sorgen macht, würde mich interessieren, wie man die lokalen DAten von nem haufen Clients managen bzw. sichern will.
naja - mich gehts ja nix an...
Weiss ja nicht was das für ein laden ist, aber wenn man sich da um den "Support" von gemappten laufwerken Sorgen macht, würde mich interessieren, wie man die lokalen DAten von nem haufen Clients managen bzw. sichern will.
naja - mich gehts ja nix an...
