Ankündigung

Einklappen
Keine Ankündigung bisher.

Netzwerkverkehr mitlesen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    Vielen, vielen Dank für eure Hilfe aber ich hab soeben das Problem gelöst.
    Fehlerursache: In der Wasseraufbereitungsanlage, die das Protokoll an den Moxa sendet, war das Protokoll nicht aktiviert. Dies wurde mir gerade vom Hersteller mitgeteilt und die haben dass dann gleich geändert.
    Und schon bekomm ich meine Daten sauber auf der Visu angezeigt.
    Danke nochmal an alle.
    Gruß Helmut
    Gruß Helmut

    Kommentar


      #17
      @tbi
      Ja stimmt, habe wohl zu kompliziert gedacht...

      Zitat von kape147 Beitrag anzeigen
      Mal ne bescheiden Frage: wie hast du denn das an's laufen bekommen - zwei PC's mit identischer IP-Konfiguration (MAC UND IP) zu gleichen Zeit im gleichen Netz?
      Das mit dem "nicht filtern" war falsch von mir ausgedrückt: Wenn ICH Netzwerkprotokolle entschlüssel, dann nehme ich 2 Systeme, mehr nicht!
      Nur darauf war es gemeint.

      Zum Thema: Mehrere Systeme mit gleicher IP/MAC: Klar geht das, es wird nur nicht wirklich richtig funktionieren, was ja auch der Grund fürs Debugging war
      So ähnlich kann man das ja auch beim Spoofing machen: Das Switch "denkt" dann beispielsweise, an Steckplatz 1 UND Steckplatz 2 sei das gleiche Gerät. Teilweise wird dann das Paket eben an beide Steckplätze gesendet.

      Nehmen wir jetzt mal an, es wird beim Protokoll normalerweise Broadcast genutzt, und die Clients "lauschen" nur, dann kann das tatsächlich funktionieren, 2 Systeme mit identischer Mac/IP im Netz. Zumindest so ein bischen...

      Derartige Späße schafft man immer wieder. Ohne hoffentlich zuuu arg OT zu gehen: Um Router zu "verstecken" wurden die Router so konfiguriert, dass TTL nicht reduziert wurde. Gleichzeitig wurde eine bestimmte Trafficart "umgeleitet". Das waren nur wenige Byte/Stunde. Ok, trotzdem im Ring geroutet unschön :P
      Keine Garantie auf Richtigkeit! Bitte nicht zu Hause nachmachen!

      Kommentar


        #18
        @rb84
        Sorry - aber das hat mit seriöser Netzwerktechnik nichts zu tun!

        "Um eine Kommunikation zwischen zwei technischen Geräten aufzubauen, muss jedes der Geräte in der Lage sein, dem anderen Gerät Daten zu senden. Damit diese Daten bei der richtigen Gegenstelle ankommen, muss diese eindeutig benannt (adressiert) werden."

        Wie willst du Daten von PC1 mit IP 192.168.1.2 und MAC 08-00-27-00-44-6C auf den PC2 mit IP 192.168.1.2 und MAC 08-00-27-00-44-6C schicken - das erklär mir mal!
        ______________________
        Grüße
        Klaus

        Kommentar


          #19
          Zitat von kape147 Beitrag anzeigen
          Wie willst du Daten von PC1 mit IP 192.168.1.2 und MAC 08-00-27-00-44-6C auf den PC2 mit IP 192.168.1.2 und MAC 08-00-27-00-44-6C schicken - das erklär mir mal!
          Nein, die Situation ist Anders!

          Du hast 2 Clients (beide 192.168.1.2) und einen Server (192.168.1.3).

          Der Client soll ein UDP Paket an den Server schicken, um sich "anzumelden" und eines um sich "abzumelden". Im angemeldeten Zustand sendet der Server UDP-Pakete an den Client.
          (vereinfacht dargestellt).

          Client A sendet nun von IP Adresse 192.168.1.2 das Anmeldepaket an den Server, der Server sendet ab diesem Zeitpunkt einen permanenten Stream an 192.168.1.2.

          Client B sendet wiederum von IP Adresse 192.168.1.2 (also die Gleiche) ein Anmeldepaket. Der Server trägt B nicht in die Clientliste ein, da er Client A und B nicht unterscheiden kann und "denkt" er haben den Client bereits in seiner Liste.

          So und je nach Netzwerkhardware funktioniert das jetzt tatsächlich, auf "IP Ebene" sogar sicher!

          So und das wird man im NORMALFALL natürlich so nicht machen. Nehmen wir jetzt aber an, jemand erstellt für die Clientseite eine virtuelle Maschine mit hardcodierter Mac und IP.
          Diese verteilt er nun, und so eine Situation kann real entstehen!

          So, und das bitte mal in "der Natur" debuggen!

          Falls jetzt kommt: "Gibts nicht!", da habe ich noch die Story einer "betriebswirtschaftlichen Standardsoftware" in VBA geschrieben auf Lager, welche auf eine Access-Datenbank (hardcodiert) mit hardcodiertem Passwort auf einem Windows-Server (Freigabe auf XP Rechner) zugreift.
          Keine Garantie auf Richtigkeit! Bitte nicht zu Hause nachmachen!

          Kommentar


            #20
            Zitat von rb84 Beitrag anzeigen

            So und das wird man im NORMALFALL natürlich so nicht machen.
            Sag ich doch - hat mit seriöser Netzwerktechnik nix zu tun - das ist gepfusche vom Feinsten! Lass da mal jemanden nach dem Fehler suchen, wenn die Pakete plötzlich nicht mehr ankommen - welcher normal denkende Netzwerker vermutet "absichtlich" eingerichtete PC's mit identischer IP /MAC im Netz
            ______________________
            Grüße
            Klaus

            Kommentar


              #21
              Zitat von kape147 Beitrag anzeigen
              Lass da mal jemanden nach dem Fehler suchen, wenn die Pakete plötzlich nicht mehr ankommen - welcher normal denkende Netzwerker vermutet "absichtlich" eingerichtete PC's mit identischer IP /MAC im Netz
              Du musst dich nur reinversetzen...
              Genau wie ein SSO Login (vor Kurzem gesehen). Da war wohl "Kostenoptimierung" im Spiel. Nur der Laptop des Managers sollte Zugriff haben. Die "Software" war extern eingekauft worden.

              Die Lösung ist denkbar einfach. Man nehme "Ich bin BWLer, hab 0 Plan, aber Kostenoptimierung" und "Ich bin Inder, hab ne Kurzschulung gemacht, und erstells für 100€".

              Decompiler eingeschaltet, BINGO!

              if(RemoteHost.equals("XXX.XXX.XXX.XXX")
              Global.Login = true;

              Lalalalalalala.....

              Ähnlich sind im Übrigen auch "Verschlüsselungen" diverser Netzwerkprotokolle aufgebaut.
              Zertifikate findest du meistens hartcodiert irgendwo im Sourcecode.
              Bei .NET hast du es in wenigen Minuten...
              Keine Garantie auf Richtigkeit! Bitte nicht zu Hause nachmachen!

              Kommentar


                #22
                Zitat von kape147 Beitrag anzeigen
                Sag ich doch - hat mit seriöser Netzwerktechnik nix zu tun - das ist gepfusche vom Feinsten! Lass da mal jemanden nach dem Fehler suchen, wenn die Pakete plötzlich nicht mehr ankommen - welcher normal denkende Netzwerker vermutet "absichtlich" eingerichtete PC's mit identischer IP /MAC im Netz
                Normalerweise sollte sich einer der PCs, zumindest wenn sie unter Windows laufen, mit einem Adresskonflikt abschalten. Ich hatte da da mal einen lustigen Fall. Wir hatten einen Server aus Altersgründen abgeschaltet und durch eine virtuelle Maschine ersetzt. Die IP-Adresse war die selbe. Aufgrund eines Unfalls bei Arbeiten am Notstromdiesel ist es im gesamten RZ zu einem Stromausfall gekommen. Nach und nach wurden alle Maschinen wieder eingeschaltet. Auch die stillgelegte. Die Anwendung hat dann nicht mehr richtig funktioniert. Zeitweise konnte ich mich mit RDP auf der Maschine verbinden und habe sie durchgestartet. Ich konnte mich von diesem Zeitpunkt an gar nicht mehr verbinden. Ich hab es dann mit VNC probiert, obwohl ich wusste, dass das auf der virtuellen Maschine gar nicht installiert ist. Ergebnis war, dass ich auf der alten Kiste gelandet bin. Seit dem ist die alte Maschine physisch vom Netz getrennt.

                Kommentar


                  #23
                  Hi,

                  das ist nicht verwunderlich. Denn innerhalb eines IP Segments wird über ARP adressiert und basiert auf MAC Adressen. Jedes Interface hält dazu eine Liste von Mapping-tabellen. Alle Interfaces fragen sich im Segment immer wieder welche MAC hat IP:... Erzähl es IP:....

                  Mit Wireshark kann man das nett mitlesen, kann ich nur empfehlen

                  Gruß Tbi

                  Kommentar

                  Lädt...
                  X