Logfile für WoL

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Re,

    Karva schrieb:

    Einarbeitung und Aufwand verbunden sein wird.
    Aber, aber ... das gehört doch dazu und macht Spaß! ;)

    Logfiles greppen / Fehlermeldungen suchen ist aber etwas, das man überall braucht, auch bei anderen Betriebssystemen.

    Ich hab allerdings noch nicht rausgefunden, ob der ASD ein eigenes Logfile schreibt, oder das auch in "messages" ablegt, oder über den "syslog" abhandelt ...

    Sc0rp
  • Tach auch,

    hier hat der Spaß "ein Loch". :D


    Mein Problem ist, dass ich erkennen möchte von welchem Port aus der NAS von der Fritzbox geweckt wird.

    Ich denke hier bin ich an der NAS falsch und sollte eher in die FB schauen. Nur leider bietet die hier nicht wirklich was.


    Mein gesamter Hintergrund des Thread stammt von folgendem:

    Hin und wieder startete mein NAS automatisch. Ich habe mich lange gewundert woran das liegt und kam durch ausprobieren auf folgende Erklärung:

    In meiner Fritzbox habe ich einige Ports (z. B.: 21 und 22) auf die NAS geforwarded. Gleichzeitig habe ich die Funktion aktiviert, dass bei Zugriff von außen der NAS gestartet (WoL) werden soll.


    Da mein NAS per WLAN verortet ist, hat diese Funktion nicht funktioniert.

    Die Fritzbox startet nur Geräte, die am LAN Port angeschlossen sind und dies wurde mir auch vom AVM Service bestätigt.


    Jetzt wurde ich eines besseren belehrt:

    Die Fritzbox startet einen via WLAN angebundenen Teilnehmer nicht mit einem WoL Package. Daher hatte dies bei mir auch nicht funktioniert. Jetzt kommt es vor, dass nach einer gewissen Zeit die Fritzbox "vergisst", dass der Teilnehmer ein WLAN-Teilnehmer war und dann doch bei Port-Zugriff ein WoL sendet.


    Da von außen wohl doch einige Zugriffe stattfinden (Portscannern?!) scheinen die hin und wieder das WoL auszulösen.

    Ich habe diese Weck-Funktion in der Fritzbox deaktiviert und siehe da: Die NAS bleibt aus.


    Jedoch möchte ich mein Netzwerk so erweitern, dass ich von außen auf die NAS komme und diese auch starte.

    Um durch eine Portbegrenzung dieses "unbeabsichtigte" Starten zu verringern würde ich gerne wissen, wieso und von welchem Port mein NAS geweckt wurde und in welchem Logfile dies steht.

    Grüße
    Karva
    Eins ist sicher: Die Platte wird sterben. Mach ein Backup.
  • Tagchen,

    ja ... das ist recht tricky, denn die Fritze weckt die Box ja nicht auf einem Dienste-Port auf, sondern eine Anfrage von außen triggert die Box dazu an, das Gerät per WoL zu starten. Im WoL-Paket wird übrigens Port 9 gesetzt ... aber das WoL nur auf Layer 2 funktioniert ist das eh unwichtig.

    Das die Fritze für so etwas kein Log hat, wundert mich etwas ... Welche hast du? Zur Not musst du eben einen "WAN-Mitschnitt" machen, und das später mit Wireshark auswerten.

    Zum Zweiten gibt es massenhaft Scans im Netz der Netze ... ich hatte früher schon mit meinem fli4l mehr Probleme mit der Größe des Logfiles als mit allem Anderen - von daver mache ich auf der Fritze keine Portfreigaben mehr außer Port 22 (SSH) auf meinen Banana Pi (als Jumphost). Alles Andere läuft nur über VPN auf die Fritze ...

    Sc0rp
  • Tagchen,

    derzeitig habe ich eine 6390 CABLE. Hier wird von Unitemedia vieles gesperrt. Diese Woche wird aber umgestellt auf eine 6490 Cable, was aber die Sachen nicht beser machen wird. :D

    Port 22 ist sicher eine gute Sache, widerspricht sich jedoch mit SRCDS und TS-Server. Also ein paar mehr Freigaben benötige.
    Evtl. lag es am Port 21. Wenn ich den mal entferne wird es evtl. ein Stück besser.

    Grüße
    Karva
    Eins ist sicher: Die Platte wird sterben. Mach ein Backup.
  • Re,

    Karva schrieb:

    Port 22 ist sicher eine gute Sache, widerspricht sich jedoch mit SRCDS und TS-Server. Also ein paar mehr Freigaben benötige.
    Naja, da würde ich mir aber auf jeden Fall noch ein zusätzliches "Firewall-Gerät" dazwischen basteln ... vor allem müsste man schauen, ob man diese Dienste ordentlich "sandboxen" kann, damit der Schadensradius ordentlich begrenzt ist. Da würde ich nochmal ordentlich Google befragen, wie man die einzelnen Server-Applikationen extra absichern kann. Und in diesem Szenario wäre evtl. auch eine VM angebracht - je nach Userzahl des TS / SRCDS.

    Karva schrieb:

    derzeitig habe ich eine 6390 CABLE. Hier wird von Unitemedia vieles gesperrt.
    Ich habe auch eine Kabel-Box (bin ja Dual-Homed :P), aber von "Sperrungen" weiß ich nix - sie versuchen zwar P2P-Verkehr zu blocken, aber schon beim (ordentlichen) Einsatz von TLS wird das schwierig ;).

    Karva schrieb:

    Evtl. lag es am Port 21. Wenn ich den mal entferne wird es evtl. ein Stück besser.
    Dennoch reagieren die IAD's bei dieser Geschichte lediglich auf eintreffenden Verkehr auf dem jeweiligen Port - ob der gut oder böse, bzw. gewollt oder ungewollt ist, können Die gar nicht entscheiden - sprich bei entsprechenden Portscans schmeißen die immer das WoL-Paket raus. D.h. wenn du diese Ports entfernst wird es ja nach Bedrohungslage mal besser / mal schlimmer - kommt immer gerade auf die aktuell bekannten Lücken an ;)

    Sc0rp
  • Tach auch,

    Port 22 brauche ich für sFTP und rsync via ssh. Hier arbeite ich ja mit Verschlüsselung und authoriertem Passphare. Auch der User für dieses Unterfangen hat nur beschränkte Rechte. Daher würde ich mir hier erstmal keine Sorgen machen.
    Andere Meinungen bitte melden.

    TS und SRCDS haben jeweils einen eigenen User ohne Rechte. Reicht das nicht? Ich ging davon aus, dass mit solchen arten von Usern wenig Schindluder getrieben werden kann.


    Sc0rp schrieb:

    Ich habe auch eine Kabel-Box (bin ja Dual-Homed :P), aber von "Sperrungen" weiß ich nix
    Echt nicht? Schon via Telenet auf der Box gewesen? :D
    Hast du dort einen Logeintrag gefunden, welcher Port ein WoL auslöst? Ich nicht. Ob dies jetzt eine "Sperre" ist, oder einfach nicht gelockt steht auf einem anderen Papier.

    Sc0rp schrieb:

    sprich bei entsprechenden Portscans schmeißen die immer das WoL-Paket raus
    Genau und da Scan/Script-Kiddies bekannte Lücken oder gleich FTP Zugänge scannen ("Pub" glaub ich heißen die Teile), würde mir evtl. das Port 21 Entfernen einiges bringen.

    Grüße
    Karva
    Eins ist sicher: Die Platte wird sterben. Mach ein Backup.
  • Re,

    Karva schrieb:

    Echt nicht? Schon via Telenet auf der Box gewesen?
    Was'n Telenet? Und was macht man damit? :D
    Und falls du Telnet meinst ... nein, würde ich auch niemals tun! Das gehört auch sowas von verboten ... besonders im Kabelnetz! (Shared Medium!) Auf dem Kabelmodem bin ich aber schon drauf gewesen *duck-und-weg* ...

    Karva schrieb:

    TS und SRCDS haben jeweils einen eigenen User ohne Rechte. Reicht das nicht? Ich ging davon aus, dass mit solchen arten von Usern wenig Schindluder getrieben werden kann.
    Geht hier nicht um den User, sondern Lücken im Server (Software-Bug) selber, mit denen man sich höhere Rechte ergaunern kann, da hilft dir auch kein unpriviligierter Benutzer - der wird ja dann"aufgebohrt" :P. Daher besser jailen, oder sandboxen ... einfach mal ein bischen rumsuchen was noch so geht, um solche Dienste abzusichern - wie schon geschrieben, wäre das auch ein Fall für "echte" VM-Abschottung ... hängt natürlich maßgeblich vom Sicherheitsempfinden ab ;).

    Karva schrieb:

    Hast du dort einen Logeintrag gefunden, welcher Port ein WoL auslöst? Ich nicht.
    Nope, meine F!B-FW-Version ist noch 5.xx ... also uralt. Ich betreibe meine Box ja hinter dem Kabelmodem, von daher anderer Aufbau.

    Karva schrieb:

    Genau und da Scan/Script-Kiddies bekannte Lücken oder gleich FTP Zugänge scannen ("Pub" glaub ich heißen die Teile), würde mir evtl. das Port 21 Entfernen einiges bringen.
    Naja, offene FTP-Zugänge sind nur beliebt, solange sie breitbandig sind ;). Aber es kommt eben auf die Lücke an ... wenn sowas wie Heartbleed die Runde macht, nehmen auf einmal die Scans auf Port 22 überhand ;) - kommt also immer auf die Lücke an.

    Btw. Port 21 brauchst du ja auch nicht und für die TS / SRCDS würde ich i'was Hohes nehmen - zw. 30.000 und 50.000.

    Sc0rp