michaelmeier

Unter welchem System läuft der AppServer denn?

Win2003

Und wieviele Nutzer brauchen denn wirklich administrativen Zugang?

Da der Server von einem Dienstleister betreut wird sach ich mal: knapp 20 Administratoren mit Admin-rechten + 5 Applikationsbetreuer mit Rechten des technischen Users haben Zugriff.

Also Zugangsdaten nur für Admin und den User, unter dem die App läuft lesbar. Wobei ja nichtmal für den Admin, der kann sich dann halt nur die nötigen Rechte holen im Zweifel, aber das fällt ja auch auf.

ansonsten ist das ja eher wie das Henne/Ei-Problem. Du willst keine Zugangsdaten in irgendwelcher Art hinterlegen, aber gleichzweitig muss sich für einen zugriff irgendwie authentisiert werden. Egal wie du das machst, außer durch solche "externen Maßnahmen" kann diese Daten jeder rausfischen, abfangen was auch immer, der Zugsng hat. Mit externe Maßnahmen meine ich z.B. Zugriffsbeschränkung auf die Daten, Zugriff nur über eine IP u.ä., also die mit den Zugangsdaten direkt nichts zu tun haben.

Meine Befürchtung. Schade, oder?

Also ok, das ist alles schon schwieriger als einfach eine Textdatei auszulesen... hm... habt ihr eigentlich kein Controlling, was die Buchungen prüft?

Falsche Buchungen sollten doch sehr schnell jemand auffallen.

*lol*

Nee, würde nicht. Da ich mit dem Login entsprechende Kreditoren und Debitoren anlegen kann und dort ohnehin eine hohe Fluktuation herrscht, würden neue Einträge kaum auffallen. Und wenn der Betrag in angemessenem Rahmen bleiben würde, dann würde das erst sehr spät auffallen.

Da läuft soviel Kohle durch das System - Kleinbeträge fallen da kaum auf.

Es geht (in diesem Konkreten Fall) um ein Modul zum scannen und automatischen Verbuchen von Rechnungen.

Hierbei hat der Anwender den Client installiert und scannt bei sich die Rechnungen. Diese werden im neuen Format mit sämtlichen Daten an den Applikationsserver übergeben. Der Applikationsserver wiederum schreibt die Daten zum einen in die Datenbank, zum anderen nimmt er automatisch die entsprechenden Buchungen in SAP vor.

Für die Verbindung zur Datenbank sind entsprechende Konfigurationsdateien hinterlegt. Hierbei ist aber die Datenbank weniger interessant - diese dient (hauptsächlich) zur Aufbewahrung der Rechnungen sowie zur Vorhaltung von Steuerinformationen (hier im Sinne von: wer hat was wann mit welcher Belegnummer gebucht, ...). Der interessante Teil ist die Weiterleitung und Verbuchung in Richtung SAP. Hierfür sind ebenfalls entsprechende Konfigurationsdateien inkl. Passwort angelegt.

Für den Austausch zwischen dem Applikationsserver und SAP gibt es einen Scheduler, der die Jobs (und diverse weitere zwecks Kreditorenabgleich etc) regelmäßig antriggert.

Soweit, so gut. Bzw. so unschön. Kurz formuliert: auf dem Applikationsserver liegen Benutzerdaten für SAP vor, welche schön was buchen dürfen. Natürlich hat nur ein kleiner Kreis Zugriff auf den Applikationsserver (sowohl für den technischen Applikationsuser als auch für den administrativen Account), aber jeder dieser User kann - sofern er es drauf anlegt - die entsprechenden Logindaten rausfischen.

Natürlich kann sich der SAP-User nicht direkt via Gui Anmelden (kein Dialog-User), allerdings kann man nun natürlich entsprechende Bapis stricken und in Richtung SAP feuern. Sehr unschön.

Daher meine Frage: gibt es für solche Settings auch Möglichkeiten, ohne Passwörter in Konfigurationsdateien auszukommen?

Hmm...

Wie willst du dich denn da durch ein Skript anmelden, ohne die Daten irgendwo hinterlegt zu haben? die nutzung von digitalen Zertifikaten ohne Passwort ist ja wie ein Private Key ohne Passwort, bringt also auch nicht viel wenn das jeder (der Zugriff hat) Auslesen kann.

Ich wüsste schon vom Ansatz her keine Idee wie man das (automatische Anmeldung durch ein Skript) denn ohne irgendwo hinterlegtes PW machen sollte. Oder hast du da eine Vorstellung? Ja, so ein Zertifikat bzw ein PK ist ja eine Idee, nur kann den ja jeder mit Zugriff auf den Server kopieren und auch nutzen für eine Anmeldung, also keine Lösung.

Ich dachte da eher an SingleSignOn.

Einmal angemeldet, alles pocco.

Nein?

Also wenn du bei der Anwendung einen Pfad für das Config-File angeben kannst, kannst du es ja in einem mit Truecrypt verschlüsselten Laufwerk bereit stellen. Somit müsste ein eventueller Eindringling erst einmal das Passwort davon haben, um Zugriff zu bekommen. Dafür muss der normale User natürlich jedesmal das File erst noch mounten, bevor er mit dem Programm Zugriff hat.

Die Frage die sich mir stellt ist aber folgende: Willst du verhindern, dass interne User Mist bauen, oder willst du den Fall verhindern, dass jemand, der da nichts zu suchen hat, Zugriff erhält?

Existieren für jeden User in der Datenbank einzelne User, oder gibt es da nur Gruppenaccounts, die mehrere User sich teilen? Zumindest die Insert/Update/drop-Rechte u.s.w. sollten wirklich nur die User haben, die sie auch wirklich benötigen.

jupp - mit nem passwort in dem batchskript, dass den container mountet.

die katze beißt sich da schön watt in den schwanz.

bzgl. der datenbank: ich will verhindern, dass interne user mist bauen. dass jemand abteilungsfremdes überhaupt auf server a (der mit dem batchfile inkl. Passwort) kommt - nee, das wird schon unterbunden.

Je nach DB-Systen (wenn wir von einer DB ausgehen für die Datenhaltung) gar nicht. Für einen Zugriff auf die Daten brauchst du eine Anmeldung, ist halt so. Und bei Skripten ist es auch relativ einfach die zugriffsmethode auszulesen, selbst wenn du die Zugangsdaten verschlüsselt irgendwo ablegst.

Ack. Das ist ja der aktuelle Stand und Hintergrund meiner Frage.

eine Idee ist noch, den Zugang für den DB-Zugriff auf eine Rechner zu beschränken. Bei MySQL (andere DBMS ja wohl auch) kannst du für jeden User noch angeben, von welcher Adresse aus er Zugreifen darf.

Prinzipiell: ja.

Es ist nunmal so, dass ein entferntet Zugriff eine authentifizierung braucht. Die musst du irgendwo ablegen. Wenn das nicht interaktiv geschieht musst du auch evtl. ein Passwort irgendwo hinterlegen. dieses Passwort kannst du natürlich auch irgendwo geschützt ablegen, nur auch das muss ja wieder irgendwo hinterlegt sein. Bei vielen Usern mit Zugriff darauf kannst du gar nicht verhindern, dass da niemand rankommt. Du kannst das nur soweit es geht einschränken.

Jupp - ich befürchte es.

Z.B. dass sich an der DB nur ein Rechner anmelden kann, bzw der User nur von einer IP-Adresse. Oder aber du legst diese Applikationen auf einem Server ab, der nur von einer einzigen Person benutzt werden kann. Also dein "App-Server" hat eben keine Erlaubnis für alle möglichen Leute aus der IT-Abteilung.

Wenn dennoch viele ein Skript aufrufen müssen kannst du diesen aufruf ja veröffentlichen, aber eben auch restriktiv. Z.b. ein Skript auf einem Server der für alle zugänglich ist, dieses Skript meldet sich, per private key, über ssh am App-Server an mit einem User mit ganz eingeschränkten Rechten und führt dort das eigentliche Skript aus. die ausgabe sieht ja der aufrufende User, kann aber sonst nichts tun. Datenabfragen kannst du so ähnlich machen.

Ja, darüber habe ich auch schon nachgedacht. Identity-Files hinterlegen, Verbindungsaufbau per SSH mittels I-File und dann auf der anderen Maschine die Befehle absetzen. Dumm nur: natürlich darf sich der technische User nicht an der anderen Maschine anmelden wg. Sicherheitsrisiko. Da gehts dann nur per sudo.

Mag sein dass das platt formuliert ist, aber es gibt nunmal keine andere möglichkeit einen Zugriff zu automatisieren, ohne irgendwo etwas zu hinterlegen. Deswegen sollte der Benutzer der mit dem hinterlegten Zugriff benutzt wird eben kein root o.ä. sein.

Na, nen root ist es natürlich nicht. Aber eben (notwendiger Weise) ein User mit Schreibrechten in den entsprechenden Schemata. Schliesslich soll er ja inserts und updates auf der Datenbank fahren.

Wie gesagt: das war meine Befürchtung. Eigentlich traurig, oder? Tausende von Authentifizierungsverfahren aber da wurde noch nix neues gebaut. Ein Trauerspiel.

Bei meinem letzten AG hatte erstmal auch die IT Vollzugriff auf alle Server (natürlich auch nicht überall Admin-Zugriff, aber halt auch auf Servern woanders Schreibzugriff auf einige Bereiche), die gesamte IT. Das wurde dann später geändert, dass nur die Netzwerkabteilung Zugriff hatte und der Rest (softwareentwicklung) eben zur Not zu denen musste wenn da was auf nen Server musste o.ä.

Am Ende wurde auch das eingeschränkt, mit den neuen Servern, und nur die beiden Abteilungsleiter hatten Vollzugriff, die anderen Mitarbeiter bei den Netzwerkern hatten einen eingeschränkten Zugriff und konnten selbst nicht mehr alles. Die waren natürlich auch nicht immer glücklich darüber, aber so ist das eben wenn du dir um die Sicherheit deines Netzes Gedanken machst.

Ja, das ist ja das Standardverfahren. Aber es geht dann eher um organisatorische Fragen im Umgang mit der Serverinfrastruktur und schränkt das Problem auch nur auf eine kleinere Gruppe ein. Je nach Unternehmen(sgröße) kann dieser Kreis aber natürlich auch schnell mal 20 Mann umfassen. Und egal wie ich es drehe und wende, solange die Zahl > 1 ist habe ich da einfach ein Problem.

Mit anderen Worten: gibt derzeit nix anderes. Schade. Muss man sich mal Gedanken machen. Ich behaupte: da kann man so manchen Euro mit verdienen.

Also auf liebe Fi-ler... super Projektthema für die nächste Runde.

Lösungen bzw. Implementierungsvorschläge bitte CC an mich.

Wieder ernsthaft: da muss man sich wirklich mal Gedanken machen. Trauerspiele dieser Art müssen (finde ich zumindest) nicht sein.

Btw: Wie siehts denn in dem Umfeld mit Kerberos-Authentifizierung o.ä. in dem Umfeld aus? Dann wäre ich immerhin das Problem los, dass da Daten im Klartext in einem Konfigfile liegen. Gibt zwar schöne neue Probleme, aber Schritt 1 wäre doch damit behoben, oder nicht?

Ich muss da mal drüber nachdenken. Dumm nur: während der EM werde ich da wohl kaum dazu kommen. Und bis danach habe ich es sicherlich wieder vergessen.

Thx @ all für die rege Beteiligung und Anregung!

@Crash: vielen Dank für deine ausführliche Antwort. Aber ich glaube, wir reden da aneinander vorbei.

Bei lokal hinterlegten Klartextdaten besteht immer das Problem, dass jeder User, der physischen Zugriff auf den PC hat, auf dem diese hinterlegt sind rein theoretisch dran kommen kann. Daher sollte das auch möglichst vermieden werden.

Das ist klar, aber in den meisten Fällen nicht zu ändern.

Verbindungen übers Netzwerk sollten möglichst verschlüsselt werden und mit Zertifikaten abgesichert werden. Ich verwende für die SSH-Verbindung zu meinem Root-Server z.B. ein Zertifikat, das auf einem USB-Stick gespeichert ist. Somit ist die Verbindung verschlüsselt und nur mit meiner private-key-Datei kann man sich per remote dort einloggen.

Jupp - Standardverfahren für SSH. Trifft hier aber nicht zu.

Lokal sind alle Benutzer von mir eingerichtet und nur ich habe die Passwörter.

Die einzige Möglichkeit, an meine Daten zu kommen wäre also, wenn jemand meinen privaten SChlüssel klauen würde (dann bräuchte er aber immer noch zwei Passwörter, um Root-Rechte zu erhalten - meines und das vom root), lokalen Zugriff hat und das root-Passwort kennt, oder aber die Festplatte ausbaut.

Lokale User. Ein Admin. Full ack. Ebenfalls hier nicht zutreffend.

Das Passwort der Datenbank ist ein "starkes" Passwort und zum Zugriff auf PHPMyAdmin braucht man noch ein anderes Passwort, da das Verzeichnis in dem PHPMyAdmin liegt geschützt ist durch den Apache. Das Passwort dafür liegt dort nicht in Klartext, sondern verschlüsselt vor.

Trennen wir uns mal von PHP. War nur das einzige Beispiel, das mir spontan einfiel, womit die meisten was anfangen können.

Oder kennt jemand zufällig Basware?

Nein, es geht im allgemeinen um das Problem, das bei Trennung von Datenlogik und Datenhaltung auf getrennte Maschinen normalerweise immer irgendwo eine konfig-Datei mit Passwort im Klartext rumliegt. Das soll vermieden werden.

Direkt mit root-rechten auf einen Server verbinden sollte man eh unterbinden. Immer nur Verbindungen mit usern erlauben und diese müssen sich dann noch einmal als root identifizieren, bevor sie root-Rechte erlangen. So werden mindestens 2 Passwörter gebraucht.

Ebenfalls full ack, ebenfalls nicht zutreffend.

Hier mal eine kleine Richtlinie (ohne Anspruch auf Vollständigkeit natürlich):

• [*]Keine Passwörter im Klartext speichern, sondern mit hashes oder verschlüsselten Daten arbeiten (Truecrypt bietet sich da z.B. auch an, wenn denn ein Programm ein Passwort unbedingt im Klartext hinterlegt haben will).

Je weiter ich lese, desto eher glaube ich, das wir aneinander vorbei reden. Die Logik auf Server A braucht eine Möglichkeit, die Datenhaltung auf Server B zu erreichen. Ich muss für die Verbindung ein Passwort nutzen. Wie schaffe ich es, dass das, was auf dem Server A in einer Konfigurationsdatei abgelegt ist, nicht das zum Login bei der Datenhaltung erforderliche Passwort ist???

[*]Verbindungen wenn möglich verschlüsseln

[*]Digitale Zertifikate wo möglich zur Autentifizierung verwenden.

[*]Rechte konservativ vergeben.

ja, alles Standard, Überall fullack.

[*]Passwörter sicher lagern und die User auch dazu anhalten (also z.B. nicht wie das gerne gemacht wird, Zettel an den Monitor oder unter die Tastatur).

Und da kommen wir zum entscheidenden Punkt. Die Lagerung des Passwortes in einer Konfigurationsdatei ist ziemlich unschön. Wie kann ich das verhindern???

Und beim Rest: full ack, allerdings alles hier nicht zutreffend.

Wie gesagt - vielen Dank für Dein ausführliches Posting, allerdings reden wir hier aneinander vorbei. Es geht hier nicht um Serverabsicherung für Einsteiger, sondern es geht hier um ein Grundsätzliches Problem bei verteilten Anwendungen. Ich bin mir nichtmal sicher, ob es zu dem Verfahren ernsthaft eine Alternative gibt. Daher frage ich spontan mal so in die Runde, ob ihr vielleicht was wisst.

Nochmals thx a lot @Crash.

Naja, dann musst du das System eben so aufbauen, dass auf die entscheidenden Server nur die Leute drauf dürfen mit root rechten, die das müssen.

Für alle anderen aufgaben die Skripte o.ä. erledigen sollen werden neue Benutzer angelegt auf den Servern, und die dürfen nur das (sehen) was sie unbedingt brauchen.

Bei deinem php-DB Beispiel ja genauso. Da legst du für jede Anwendung eine DB an und einen Benutzer. Der Benutzer (der im Skript steht) darf dann nur das was er braucht, und nur für diese DB (Lesen, evtl. Schreiben, aber kein Create, Drop o.ä.)

Wenn jeder alles darf, ist das sowieso schonmal ein Problem.

Na, das ist ja arg platt formuliert. Aber natürlich habt mehr als eine Person (notwendiger Weise) den root-Account. Darüber hinaus haben natürlich auch mehrere User den Account unter dem (in diesem Beispiel) die Skripte gestrickt wurden. Etwas, was sich bei Teams > 1 Person kaum vermeiden läßt.

Aber es geht ja auch nicht um den Zugriff auf diese Datei. Es geht darum, diesen ganzen Batchvorgang so umzustricken, dass das Hinterlegen von Passwörtern in Batchskripten/Konfigurationsdateien/whatever nicht mehr erforderlich ist. Darum (und nur darum) geht es. Ob es dafür (mitlerweile) neue Strukturen / Verfahren gibt.

Wenn jemand Zugang zum root-Benutzer hat, sollte der schon einen verdammt guten Grund dafür haben. Und dann sollte ebendem auch bekannt sein, dass er verpflichtet ist, die Daten vertraulich zu behandeln

Ja, sicher. Aber Du weißt doch, wie das in der Systembetreuung ist. Da haben diverse Leute plötzlich Zugriff auf die Systeme zwecks Betreuung. Und sich da ausschließlich auf die Vertraulichkeit der Daten und die entsprechende Regelung im Arbeitsvertrag zu verlassen ist etwas arg dürftig. Ich hätte da lieber etwas handfestes.

MD5 wäre eine möglichkeit

Naja, klar kann ich davon nen MD5-hash erzeugen. Sicher. Den könnte ich dann übertragen und auf die entsprechenden password-Funktionen verzichten, damit ich die md5-hashes vergleichen kann. aber mal ehrlich: wo ist dann der unterschied? dann hätte ich ja wieder den klartext bzw. genau die Infos, die ich für den Login brauche.

Moin zusammen,

bei vielen verteilten Applikationen (hier: Applikationen, bei denen Programmlogik und Datenhaltung auf verschiedenen Servern liegen) findet sich an diversen Stellen das für eine Datenübertragung zwischen Logig und Datenhaltung notwendige Login im Klartext in Konfigurationsdateien.

Gibt es eigentlich eine Möglichkeit, dies zu umgehen? Denn: in den meisten Fällen benötigt man dann ja nur diese Dateien, um von anderen Servern aus entsprechende Logins zu realisieren.

Klar kann man die Dateien entsprechend absichern, aber der Zugriff ist (oft) noch immer möglich. Beispiel sei die Kommunikation zwischen einem PHP-Skript und einer Datenbank. Haben mehr Menschen außer mir die entsprechende Berechtigung das File zu lesen (z.B. root bei vservern oder so), dann war's das mit "vertraulichen" Infos in der Datenbank.

Any ideas?

^ kaffee ist fertig. milch und zucker?

< holt sich nun noch einen eigenen kaffee. schwarz, doppelt zucker.

v kann kaffeejunkies (verbrauch > 1 Kanne pro Tag) nicht verstehen und kann auch ohne Kaffee erfolgreich in den Tag starten.

3. google Treffer oder so

User hat ein Fake Account angelegt darf ich IP Adressen herausgeben?

das ist keine Anwort auf die Frage, denn: hier wird nur geklärt, dass die Daten herausgegeben werden müssen, sofern entsprechende Merkmale vorliegen.

2. Sie müssen demnach die Daten nur bei Vorlage eines derartigen Beschlusses vorlegen.

3. Sollten Sie in Ihren AGB mit den Nutzern vereinbart haben, dass Sie bei Anfragen von Dritten die Daten freigeben, sofern die Ansprüche fundiert dargelegt sind und der Nutzer der Freigabe zustimmt, kann sich daraus auch eine Herausgabepflicht ergeben.

Mit anderen Worten: ich muss - sofern ich dazu verdonnert werden. Aber von freiwillig steht da nix.

bzgl.

Allerdings sollte aufgrund eines Urteils des Amtsgerichts Mitte Berlin vom 06.09.2007 mit Az. 23 S 3/07 gegen das Bundesjustizministerium, wonach das Speichern von IP Adressen grundsätzlich gegen § 15 Telemediengesetz (TMG) verstoße, keinerlei Protokollierung beim Anbieter des Web-Angebots stattfinden.

Klingt arg nach "hätte, könnte, sollte". Aber konkretes scheint sich ja nirgendwo zu finden. Eigentlich bemerkenswert.

^ richtig - bin eh 24/7 vor ort und damit auch erreichbar. lang lebe das bw-klappbett!

< will heute früh nach hause. mehr fussball. wird aber wohl nix. einer muss ja die stellung halten.

v haut heute bestimmt früh ab und wird die spiele schön was im biergarten verfolgen.

Was die ISP angeht: sicherlich ein sehr spannendes Feld. Um aber das Ausgangsposting nochmal aufzugreifen:

Wer oder was sollte mich denn daran hindern, nach belieben die IPs rauszugeben? Gibt es da konkrete gesetzliche Vorgaben, dass ich das nicht darf?

Oder anders: was wäre denn, wenn ich die enstprechende IP einfach mal neben das Posting pinne? Verboten?

Wenn jemand da was hat: bitte mal das entsprechende Gesetz / Verordnung / was auch immer posten.

Thx a lot.

Hi,

erstmal Glückwunsch zur Entscheidung, dich mit weiteren Betriebssystemen zu beschäftigen. Sehr schön!

Zu Deinen Fragen:

Kann man ein Linux, nebst eines XP-Pro installieren und während des Bootens das OS wählen?

Ja. Bei der Installation wird ein Bootloader erzeugt und (normalerweise) in den Masterbootrecord der Platte geschrieben. Hier wird angegeben, welche Optionen zum Booten verfügbar sind (kurz und knapp gesagt). Auch wenn ich die 8.04er Ubuntu noch nicht selbst installiert habe: die meisten großen LInux-Distributionen raffen selbstständig, das noch ein anderes Betriebssystem installiert ist und passen den Bootloader entsprechend an (übrigend ganz im Gegensatz zu ***-Produkten, die immer da ziemlich gnadenlos sind).

Dann hab ich noch ein wenig Muffe, wegen der Treiberunterstüzung / nachträgliches Installieren.

Don't panic! Bei der von dir genannten Konfig sollte es zu keinen Problemen kommen. Einzig bei der ATI weiß ich nicht, ob Ubuntu mitlerweile den ATI-Treiber mitbring (ist kein OpenSource bzw. GPL, daher ist es lizenzrechtlich nicht so einfach, den Treiber zu integrieren). Das hätte zur Folge, dass die Karte keine 3D-Beschleunigerfunktionalität besitzt. Das System läuft aber trotzdem.

Wenn du die treiber installieren möchtest: bei ATI Treiber runterladen, Anweisung befolgen, fertig. Klappt in den meisten Fällen (bzw. ich habe bei älteren ATI-Karten und non-bleeding-edge-x-server-versionen nix Gegenteiliges gehört).

Aber: mach doch den Test. Zieh dir die LIve-CD. Wenn es damit rennt und du keine Probleme hast, dann zieh die Installation auf Platte. Wenn es bei der Live-CD zu Problemen kommt, dann einfach Rechner durchstarten und alles wird gut.

Dir viel Erfolg und vor allem: viel Spaß mit dem neuen Betriebssystem!

ich glaube eher, dass das thema soweit durch ist. die ausgangsfrage des threaderstellers ist hinreichend beantwortet.

Also für mich klingt die Sache eher nach Betrugsversuch als nach Interesse an Privatspähre.

jupp - und ein jeder, der nicht freiwillig und im vorauseilendem gehorsam sämtliche privaten daten offenlegt ist ein krimineller. :uli sicher. :upps

besteht zufällig eine verwandtschaft mit onkel schäuble?

wobei: du hast natürlich insofern völlig recht (wie ich gerade nachgelesen habe), dass zumindest bei abschluss von verträgen zur bereitstellung von telekommunikationsmitteln in form von leitungen eben diese verträge auf einen konkreten namen angemeldet sein muss, ja.

aber es ist schon beeindruckend, dass man - wenn man sich gedanken darum macht und themen erörtert - gleich in die kriminelle ecke gedrängt wird. sehr gesunde einstellung.

Wenn du Anonym telefonierne willst nimm ne Telefonzelle mit Münzeinwurf... Aber wisch vorher die Fingerabdrücke von den Euros ;o)

gibts denn noch richtige telefonzellen? habe in meiner umgebung lange keine mehr gesehen. gibt da nur noch diese freiluftdinger mit minidach. das ist - vorsichtig formuliert - unschön. nebenbei: es sind nicht nur die euronen, sondern auch die zifferntasten und der hörer.

Vorallem bin ich der Meinung wenn der Staat oder die Polizei herausfinden will wem die Karte oder die Nr. gehört, dann geht das im Normalfall innerhalb von einem tag! Da bringt das mit anonymen Namen und so auch nix!

naja, das würde ja nur über entsprechende positionsbestimmungen gehen - und die sind nunmal relativ ungenau.

wie dem auch sei, interessant ist ja schon, ob es möglich ist. ob nun tatsächlich eine umsetzung erfolgt, sei mal dahingestellt.

thx a lot.

werde es am wochenende ausprobieren.

ich hoffe nur, ich vergesse nicht, die karte bar zu zahlen...

Warum ich überhaupt auf die Idee komme:

Stoppt die Vorratsdatenspeicherung! - Bundesweiter Aktionstag gegen Ãœberwachung mit Handy-Kartenaktion (26.05.2008)

Das wollte ich mir mal näher anschauen.

Man weiß nie, wofür das gut ist.

ja, das ist ja gerade die große Frage.

Wenn ich es richtig interpretiere, dann liegt dem Starterpaket ein Schreiben mit Nummer und SIM-Kartennummer bei. Dies schnell online (theoretisch mit beliebigen Daten) registriert, 6 Stunden auf Freischaltung warten und feuer.

Oder habe ich das falsch verstanden?

danke für das feedback. meinte allerdings weniger die technische verfügbarkeit des netzes als viel eher ob ich damit tatsächlich an eine anonyme sim-karte komme.

sorry, hab ich mich etwas umständlich ausgedrückt.

Moin zusammen,

hat jemand Erfahrungen mit den Handy-Tarifen vom Aldi?

Wenn ich es richtig verstehe, dann muss ich da nur hinlatschen, das "Starter-Set" aufs Band legen, bar bezahlen und kann dann loslegen, richtig?

ALDI-Talk

D.h. ich kann dann anonym telefonieren? Hat da jemand Erfahrungen gemacht? Ist das wirklich so? Oder muss ich da noch Verträge u.ä. ausfüllen?

Thx in advance...

Sogenannte "Hacker-Tools" dürfen afaik benutzt werden, wenn man ein berufliches Interesse daran hat und man für das Netz zuständig ist, bzw den Auftrag hat, dieses zu analysieren und zu warten.

naja, das kommt ganz darauf an, wie man das Gesetz interpretiert.

Fangen wir mal harmlos an. Netzwerk sniffen - gerade am Internetgateway -heißt u.U. auch Passwörter für http-Seiten greppen.

Dazu §202a Abs 1 Strafgesetzbuch:

§ 202a

Ausspähen von Daten(1) Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind, unter Überwindung der Zugangssicherung verschafft, wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft.

Ist das da schon erfüllt?

Besser §202b Strafgesetzbuch:

§ 202b

Abfangen von DatenWer unbefugt sich oder einem anderen unter Anwendung von technischen Mitteln nicht für ihn bestimmte Daten (§ 202a Abs. 2) aus einer nichtöffentlichen Datenübermittlung oder aus der elektromagnetischen Abstrahlung einer Datenverarbeitungsanlage verschafft, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit Geldstrafe bestraft, wenn die Tat nicht in anderen Vorschriften mit schwererer Strafe bedroht ist.

damit wäre man dann in jedem Fall dran.

Der neue Paragraf ist dabei eher uninteressant.

Wie dem auch sei: als Admin sage ich: hey, wenn es dem Job dient - dann muss man mal ne Runde Gesetze dehnen.

Aber es wird nicht lange dauern, bis der erste dafür vor den Kadi gezerrt wird.

oder alternativ: servicepacks und updates von einer anderen maschine aus runterladen, rüberkopieren und draufschrubbeln.

Ich möchte nicht "schnüffeln" in dem Sinne andere auszuspionieren sondern nur gucken ob hier im LAN ein Rechner konstant übermäßig viel Traffic hat

Also der Anlass, aus dem heraus man mitsnifft, ist eigentlich völlig irrelevant. Fakt ist, dass es so möglich ist, personenbezogene Daten auszuwerten bzw. Mitarbeiter zu überwachen. Je nach Betriebsvereinbarung ist man da ziemlich schnell am Allerwertesten.

Nicht umsonst ist man als Admin immer mit einem Bein im Knast.

BTW: sind das nicht inzwischen auch "Hacker-Tools", die mitlerweile verboten sind? Oder ist das Gesetz noch nicht durch?

ich möchte fast darauf wetten: mac-adressenfilter ist aktiviert, die adresse ist aber nicht hinterlegt.

wenn verbindung = gut, ip vorhanden, anderes notebook kann -> sehr wahrscheinlich, dass es der filter ist.

deinen ausführungen entnehme ich, dass das notebook auch bisher noch nicht am wlan war... korrekt?

have phun!

Ist es nicht das Betriebssystem, was da den Ausschlag gibt?

Mit anderen Worten: Wenn Du ne Vista-32bit Version hast und darauf Virtual PC installieren möchtest - ich glaube nicht, dass da die 64bit-Version läuft. Anders herum kannste bei Vista-64bit definitiv beide Versionen installieren.

Oder hab ich die Frage nicht gerafft?