cicero610y

Hallo, Der ursprünglichen Definition einer DMZ nach brauchst Du für eben diese zwingend notwendig zwei Router, also WAN <===> Router <===> DMZ <===> Router <===> LAN Da aber unter Umständen der Aufwand zu hoch ist, gibt es auch die "kollabierte DMZ" oder - wie es in Deinem Gerät steht - die "Virtual DMZ". Dabei hast Du dann eben nur einen Router: WAN <===> Router <===> LAN || V DMZ Kurz: Du brauchst nur diesen einen Router, verzichtest aber auf eine ganze Menge Sicherheit, weil zum Erreichen des LAN nur eine Hürde kompromittiert werden muss. Grüße, Florian

Hallo, Ok. Nochmal: Ein normaler Switch, der auf Layer 2 arbeitet, kennt kein ARP und schickt auch keine ARP-Requests durch die Gegend. Egal wie - er tut das nicht. Ihm ist egal, ob er kaskadiert ist oder welche Rechner an einem anderen Switch in der Kaskade hängen. Das Ding ist meines Wissens ein Layer-3-Gerät. Erst damit kennt das Gerät mehr als Ethernet und weiß überhaupt etwas von einer IP. Woher soll ein normaler Switch etwas von einer IP wissen? Er kennt das nicht, hat daher auch keinen ARP-Cache. Wie gesagt: Ein Layer-2-Switch kennt gerade mal Ethernet und muss deshalb auch nicht zwischen IP und MAC auflösen. Das macht allein der Rechner. Kommunikation - jederzeit per Ethereal am eigenen Netz nachzuvollziehen: 1.) Rechner R soll ein über Ethernet ein TCP-Paket an das lokale Gateway G senden. 2.) R kennt lediglich die IP von G 172.24.2.1, sein ARP-Cache ist leer 3.) R fragt per ARP: "Wer ist 172.24.2.1?" 4.) Wenn kein böser Junge dazwischen, antwortet G (und dann nur der!) mit ARP-Response "172.24.2.1 ist bei 00:0A:5E:1C:63:70" 5.) R trägt dieses Päärchen in seinen ARP-Cache ein. 6.) Der TCP/IP-Stack des OS von R packt nun das ursprüngliche Paket die Layer runter zusammen und schickt es über Ethernet an 00:0A:5E:1C:63:70. 7.) Der Switch dazwischen bekommt das Paket, schaut sich (je nach Bauart) die MAC an, sieht in seinem Address-Cache nach und haut es am entsprechenden Port wieder raus oder - wenn er es nicht in seinem Address-Cache hat, an alle Ports. Nicht anderes macht ARP - der Switch hat damit nichts zu tun. Grüße, Florian

Hallo! Ja nee, is klar :-) Es war halt trotzdem eine interessante Sache zum Grübeln. Habe mir da nie irgendwelche Gedanken über die Abstrahierung von ARP auf ISO/OSI gemacht. Und gerade da das so eine merkwürdige Sache ist, macht das Spaß, sich den Kopf darüber zu zerbrechen und Argumente zu finden. Grüße, Florian

Hallo! Jetzt bin ich aber auch ins Überlegen gekommen. Im TCP-Referenzmodell liegt es natürlich in Layer 2, da kommt ja nun nicht wirklich etwas anderes in Frage. Im ISO/OSI-Layer ist das eine andere Sache. Nachdem ich mir RFC826 durchgelesen habe, scheint es wohl mehrere Auffassungen geben zu können. Das RFC trifft keine genauen Aussagen über die Einordnung. Und da ARP ja nun sowohl von IP (also Layer 3) als auch von Ethernet (Layer 2) etwas wissen muss, müsste es eigentlich eher auf Layer 3 liegen (weil ein Layer nie irgendetwas aus dem Layer darüber kennt) . Andererseits kann man es nicht routen, also müsste es auf Layer 2 sein. Kurz: Ich weiß es nicht. Aber wahrscheinlich eher Layer 3. Grüße, Florian

Hallo... Was hast Du denn dauernd mit Deinem Telnet? Also: 1.) FTP-Server oder Äquivalent (z.B. SFTP-Server, ist besser); 2.) Datei auf den Rechner schieben; 3.) Telnet oder Äquivalent (z.B. SSH, ist auch besser); 4.) Dort ausführen Wo ich jetzt gerade sehe, dass es um Windows geht: Nimm für Punkt 3 und 4 einen VNC-Server/-Client oder für 1-4 PC-Anywhere oder halt irgendsoetwas mit Klickibunti. Grüße, Florian

Hallo, Wenn Du das Protokoll meinst: Das geht nicht. Wenn Du nur die Anwendung meinst: Das geht, solange Du ein anderes Protokoll sprechen kannst, dass das Kopieren etc. implementiert hat. Grüße, Florian

Hallo, Habe mich eben mal kurz eingelesen und nachgedacht. Mein Ergebnis: Ein Adressen-Cache ist nicht notwendig. Er ist natürlich sinnvoll, um eben schneller arbeiten zu können, aber für die Funktion ist er meiner Meinung nach nicht essentiell. Wieso sollte er das auch? Wenn der Adressen-Cache abhanden kommt, sucht er eben bei jedem Paket aufs neue. Ein anderer Cache ist natürlich wichtig: Ein einfacher FIFO, um zum Beispiel Pakete zwischenzuspeichern, die gerade wegen Belegung des Ports nicht abgehandelt werden können. Das ist schon klar. Aber meinst Du wirklich, dass einen Switch das ARP interessiert? Hast Du schonmal gesehen, dass ein Switch ARPs durchs Netz pustet? Sind zwar beide auf Layer 2, aber machen nichts miteinander. Der Switch lernt vielleicht durch ARP-Responses, an welchem Port welcher Rechner hängt, aber die eigentliche Auflösung in die IP interessiert nicht. Soweit ich weiß, jubelt man beim ARP-Poisoning nicht dem Switch, sondern dem Ziel-Rechner ein falsches ARP-Päärchen unter. Wir reden doch hier immer noch von nem Layer-2-Switch, oder? Das ist bekannt. Aber Du bringst nicht den ARP-Cache zum Überlaufen (und erst recht nicht den vom Switch), sondern den Adressen-Cache des Switches, also den Cache, in dem steht, an welchem Port welche MAC hängt. Grüße, Florian

Hallo! Ein Switch cachet die MAC-Adressen der Ports (also die der Clients) in einer internen Tabelle. Das ist einerseits gut (er kann so schneller und ressourcenschonender arbeiten), andererseits schlecht (man kann unter Umständen diesen Cache manipulieren oder zum Überlaufen bringen). Soweit ich weiß, muss ein Cache sogar vorhanden sein? (kann da jemand etwas dazu sagen?) Je größer der Cache, desto besser. Irgendwann wird es aber wieder unsinnig, weil man ja nun auch nicht permament umstöpselt und unbegrenzt Ports zur Verfügung hat. Grüße, Florian

Hallo! Warum auch immer da das LWP::UserAgent auftaucht - das ist eigentlich überflüssig und Du brauchst das nicht. Der entscheidende Teil ist das mit dem XML::Simple. my $xml=XML::Simple->new(); # xml-Objekt my $data=$xml->XMLin('/pfad/zur/datei',ForceArray=>1,KeyAttr=>[]) || die $!; # Struktur aus Datei foreach my $item (@{$data->{'item'}}){ # Jedes Item mit Namen 'item' durchgehen print $item."\n"; # und ausgeben } Lies Dir aber unbedingt die Dokumentation zu XML::Simple durch! Das geht sonst tierisch daneben. Mit: perldoc XML::Simple kommst Du an die Doku. Als Tipp: Benutze Data:: Dumper (blöde Smileys) um Dir die Struktur von $data anzusehen, da kommt je nach Option von XMLin() unerwartetes heraus. Viel Spaß! Florian

Hallo, Prinzipiell ist das soweit korrekt. Allerdings: Allein ein VPN impliziert nicht, dass eben dieses auch verschlüsselt ist. Ein VPN sagt lediglich, dass ein öffentliches Netz zum Transport von Daten innerhalb eines virtuellen privaten Netzes benutzt wird. Viele VPN-Implementationen hingegen bieten jedoch eine Verschlüsselung für das VPN an - schließlich ist es ohne meist ziemlich sinnlos und/oder gefährlich. Grüße, Florian

Hallo! Das ist prinzipiell machbar. Du nimmst z.B. DTR (Pin 4) und setzt oder löscht das Bit - somit hast Du zwischen DTR und GND (Pin 5) entweder einen Pegel oder keinen (also etwa 5V). Schau Dir dazu mal die manpages zu sys/ioctl.h und fcntl.h an - das sind nur ein paar Zeilen Code in C, die Du da im Endeffekt brauchst. Und zu OpenWRT sollte die Entwicklungsumgebung inklusive Cross-Compiler, Libraries und Header vorhanden sein. Mit dem TTL-Pegel kannst Du aber noch lange keine Lasten schalten... dazu bräuchtest Du idealerweise einen Darlington-Transistor und ein Lastrelais. Der Reset-Knopf Deines Rechners ist aber keine Last im eigentlichen Sinne - ein robuster Transistor (trotzdem noch Darlington~) reicht aus. Um Dir die beiden Boards aber nicht zu schrotten, solltest Du auf Potentialtrennung achten, also zwischen Rechner und dem WRT54GS einen Optokoppler oder ähnliches einplanen. Kurzum: Bastelkiste ausräumen, einen Tag löten und hacken, 5 EUR Material und Du hast Dein Ding. Grüße, Florian PS: Stromlaufplan, Platinenlayout und Code gibts gegen Bares *g*

Hallo! 100%ig verlässlich kannst Du das nicht herausfinden. Entweder Du siehst es schon im http-Header, den der Webserver zurückgibt, z.B. "Server: Apache/1.3.26 (Unix) Debian GNU/Linux" - bedenke: da kann stehen, was auch immer der Admin gerade möchte - oder du findest es mit nmap (siehe "man nmap") heraus. Aber selbst mit nmap ist das nicht wirklich zuverlässig und muss noch lange nicht stimmen. Die Klickibunti-Methode ist es, zum Beispiel http://www.netcraft.com zu benutzen (siehe Formular links oben). Grüße, Florian

Hallo! Eigentlich sollte das gehen... Im CPAN gibt es Nmap::Scanner::OS, also die Perl-Modul-Implementation zu nmap. Auf der Kommandozeile sieht das z.B. so aus: nmap -O 82.139.237.140 -P0 -p 80 (ja, ich weiß um die Warnung, die nmap dann ausgibt..., und lasst den Rechner in Ruhe, das ist meiner *g*) Das Perl-Modul funktioniert prinzipiell ähnlich, guck' halt unter: http://search.cpan.org/~maxschube/Nmap-Scanner-0.9/lib/Nmap/Scanner/OS.pm Abgesehen von den kleinen Unzulänglichkeiten ist das in Ordnung... Grüße, Florian

Hallo! Jau, das geht - zumindest teilweise. Als direkte Parameter kannst Du das nicht machen, aber in der manpage zu "req" ist ein anderer Weg wunderbar beschrieben. Sogar speziell auf eben diese Situation hin (Script oder GUI). Ich habe das auch mal benutzt, um mir ein eigenes Webfrontend für die essentiellen CA-Aufgaben zu schreiben. Hier der Auszug aus der manpage: If the prompt option is set to no then these sections just consist of field names and values: for example, CN=My Name OU=My Organization emailAddress=someone@somewhere.org This allows external programs (e.g. GUI based) to generate a template file with all the field names and values and just pass it to req. An example of this kind of configuration file is contained in the EXAMPLES section. Grüße, Florian

Hallo! Naja, ich weiß nicht - aber findest Du nicht auch, dass der OP das schon wissen sollte? Stell Dir vor, er richtet den Radius jetzt so ein, und kurze Zeit später hat er die ersten Besucher in seinem Netz, weil er immer noch denkt, das sei so alles sicher? Die Vorgehensweise eine MAC-Addresse zu setzen steht abgesehen davon auch in der Manpage von "ifconfig". Zum Mithören einer dieser Anmeldungen und dem Herausfinden eben dieser MAC habe ich nichts detailliertes geschrieben. Trotzdem sollte man doch die grundlegenden Vorgehensweisen eines Einbruchs kennen, um genau dieses bei eigenen Installationen zu verhinden, oder nicht? Grüße, Florian

Hallo! Mh - dass die MAC-Adresse aber kein eindeutiges Kriterium ist, weißt Du? Eine MAC-Adresse lässt sich ohne Probleme ändern und nach belieben setzen. Ein potentieller Angreifer sitzt eine Straße weiter und muss lediglich eine einzige gültige Anmeldung mithorchen und hat somit die MAC. Und die setzt man dann per ifconfig <Interface> hw ether <Adresse> Grüße, Florian

Hallo! Bin neu hier und werde höchstwahrscheinlich nächstes Jahr auch ne Ausbildung zum "FISI" machen :-) Nein - das ist so nicht ganz korrekt. Ausführung: WPA (so auch WPA2) ist erstmal nur ein Pseudostandard als Teilmenge von 802.11i. WPA beschreibt die drei grundlegenden Dinge Integrität, Authentifizierung und Verschlüsselung. Authentifizierung: Entweder PSK oder 802.1x (EAP und derlei Spielarten wie PEAP, EAP-TTLS usw.), gemeinhin unter dem Stichwort "Radius" (als AAA-Server) bekannt. Verschlüsselung: RC4 in seiner Implementation TKIP (siehe "WPA1") oder AES in CCMP ("WPA2"). Integrität: MIC (oder Michael oder Message Integrity Check). Nun kann man diese Dinge wild durcheinander mixen und erhält so zum Beispiel "WPA-PSK mit TKIP" oder "WPA-EAP mit TKIP" oder "WPA2-EAP mit CCMP" oder WPA2-PSK mit CCMP. Ideal ist natürlich "WPA2-EAP mit CCMP". Übrigens: RC4 selbst ist nicht "geknackt" im eigentlichen Sinne, sondern wird nur als unsicher angesehen, weil linear. Knackbar ist WEP lediglich, weil die RC4-Implementation ziemlich krank ist und zweitens in 802.11 ein paar Definitionen zur Behandlung von Paketen auf Layer PHY fehlen (die IVs müssen nicht streng monoton steigend sein usw.). Zum Mitsniffen von PSKs bei WPA/WPA2: Sinnvollerweise gehen die PSKs natürlich nicht im Klartext über den Äther, vielmehr wird vorher ein Schlüsseltausch stattfinden (MD5). Per Brute-Force kann der PSK dann jedoch auf Basis des ausgetauschten Schlüssels erraten werden. Die Hierarchie sollte also lauten: WEP64 WEP128 WEP64 mit Shared Key Authentication WEP 128 mit Shared Key Authentication WPA/TKIP mit PSK WPA2/CCMP mit PSK WPA/TKIP mit Authentifizierung nach 802.1x (vorausgesetzt, man benutzt sichere Methoden wie PEAP oder EAP-TLS o.ä.) WPA2/CCMP mit Authentifizierung nach 802.1x (gleiches wie eben gilt) Grüße, Florian