Posts by Torsten

    Hi Daniel,
    ich hätte dir auch spontan zum iFMC geraten.

    Wenn dies jedoch keine Option ist, wird es leider nicht mehr ganz so komfortabel zu lösen sein.
    Am einfachsten wäre, wenn der User - sobald er außer Haus ist - seine Rufnummer auf sein Handy umleitet. Ab Version 5 könnte die Zentrale im Browser-BLF sogar sehen ob der User die Umleitung aktiv hat oder nicht.

    Asonsten könnte man sich für die Handynummern noch eine Taste zur Direktwahl konfigurieren. Diese ist dann auch im Callmanager nutzbar.

    Hallo Christoph,
    hast du irgendwelche Module im Einsatz? Wenn ja, welche?

    In diesem Szenario sorgt nur eine Kombination von 2 gleichzeitig angemeldetenm bestimmten Usern zum Fehler, habe ich das so korrekt verstanden?

    Hi epg789,
    mit Dusnet haben wir leider in letzter Zeit keine guten Erfahrungen gemacht. Der Dienst ist teilweise nicht mehr 100% zuverlässig verfügbar. Zumindest bei uns bekannten Einzelfällen.
    Die ersten Drei Meldungen aus dem Log die du gepostetst hast besagen genau das, der Dienst antwortet nicht, läuft in Timeouts, etc.
    Würden nur diese Meldungen kommen, würde die STARFACE die Registrierung immer wieder versuchen. Die letzte MEldung aus deinem Log ist dann aber sozusagen das Stopschild von Dusnet.

    Diese Melden dort zur STARFACE ein SIP-Packet mit der Meldung 404 Not Found - bezogen auf die Registrierung von uns. Das bedeutet dass die Dusnet deinen Usernamen nicht gefunden hat und damit die Registrierung abbricht.
    Die STARFACE versucht dann natürlich erstmal nicht mehr sich mit einem scheinbar falschen Usernamen anzumelden.

    Warum diese Meldung von Dusnet kommt, müsstest du mit denen klären, diese sehen ja unsere Anmeldungsversuche und mit den Timestamps aus unseren Logs kannst du auch sehr genau sagen wann die einzelnen Schritte passiert sind.

    Hallo zusammen,

    Nili1968: die 5er läuft momentan noch in der internen Testphase. Wenn hier keine größeren Probleme ersichtlich werden sollte es Ende Oktober bzw. Anfang November soweit sein.

    epg789: In den Config-Dateien Dinge anzupassen würde ich dir nicht raten. Diese sind nicht immer update sicher und sind i.d.R. auch kein Bestandteil der BackUps (die Änderungen). Die Datei die du ansprichst ist die sip_custom.conf . Diese wird per default in der normalen sip.conf included. Du kannst also auf eigene Gefahr dort Anpassungen vornehmen bzw. testen.

    Hi epg789,
    sobald deine STARFACE über das Internet angesprochen werden kann, können Angreifer versuchen einen SIP-Peer zu knacken. Sich also mit einem Endgeräte-Profil bei dir anmelden und dann Gespräche führen.
    Genau das ist bei dir passiert. Aus dem Log-Auszug ist zu sehen das er sich veruscht mit dem Telefonnamen 9974 anzumelden. Diesen gibt es in der STARFACE nicht weshalb die Meldung "no matching peer found" geworfen wird.

    Wenn du keine externen Teilnehmer an der STARFACE anbinden musst, würde ich dir empfehlen die STARFACE durch entsprechende Firewall-Regeln von außen abzuschotten.
    Am wichtigsten ist jedoch, das auf keinen Fall deine Endgeräte-Profile nur aus Nummern bestehen. Ebenfalls sollten deine Passwörter immer von der STARFACE generiert sein. Das verhindert zwar keine Angriffe sehr wohl aber den Erfolg dieser Angriffe.

    Du kannst du Sicherheit deiner Telefonprofile automatisiert über das Modul "SIP Passwort Sicherheitscheck" prüfen lassen.

    An die externe IP der STARFACE kommen solche Angreifer recht einfach durch ein port scanning. Sobald ein Angreifer eine Antwort auf Port 5060 bekommt beginnt der Angriff. Erfahrungsgemäß fängt es an mit Registrierungen für das Endgerät 0 dann 1,2,3 usw.


    In der kommenden STARFACE 5 wird es hier übrigens eine automatisierte Black und White-List für solche Registrierungen geben. Diese Liste blockiert nach x nicht erfolgreichen Registrierungen die entsprechende Quell IP und unterbindet dadurch auch direkt eine Brute-Force attacke.


    Warum 10 COR-Regeln? Meine letzte Info ist, dass Starface automatisch die Ortsvorwahl voranstellt und so die Regel für "0" für ein "catch all" ausreicht.

    Das ist so auch erstmal korrekt.
    Problematisch wird es wenn du in deinem Ortsnetz z.B. 3- oder 4-stellige Rufnummer wählst. Diese währen für die STARFACE potentiell interne Nummern. Mit den COR-Regeln für 1-9 hast du dann aber auch diese Nummern ins Amt geleitet.

    3- bzw. 4-stellige interne Nummer erkennt die STARFACE dann natürlich trotzdem und routet diese nicht ins Amt.

    slu
    wenn du die Option für den internen Mail-Server nutzt, verschickt die STARFACE via sendmail deamon die e-mails.
    Bei der Option für den externen Mail-Server interlegst du selbst Login-Daten für einen Mail-Server bzw. für einen Mail-Account. Also z.B. deinen Exchange, dein 1und1-Account, etc. Über den dort eingetragenen Account verschickt dann die STARFACE ihre mails.

    Hi sys-tech,
    verwendest du den STARFACE internen Mailserver? Oder einen externen?
    Sofern du den internen nutzt, stelle diesen bitte auf einen externen Server um.

    Solltest du bereits deinen eigenen Mail-Server eingetragen haben, prüfe mal die Logs von diesem System. Eventuell sind dem die Mail-Anhänge zu groß.
    Hinweise auf Fehler beim Mail-Versand finden sich auch unter /var/log/starface/error.log bzw. /var/log/starface/trace.log - in diesen Logs kannst du direkt nach der Empfänger-Adresse suchen.

    Hallo ihr beide,
    die Verbindungsdaten - also wer hat wen, wann, unter welcher Nummer, etc. angerufen - werden in der Datenbank vorgehalten.
    Diese Einträge werden nicht gelöscht und sind auch Bestandteil jedes Back-Ups (sofern die entsprechende Option gesetzt ist).

    Möchte man seine Datenbank verschlanken, kann man diese Einträge direkt über die Datenbank "im großen Stil" löschen.
    Erfahrungsgemäß machen die Call Data Records i.d.R. aber keine Probleme, auch in größeren Systemen mit entsprechend vielen Einträgen.