.titleBar { margin-bottom: 5px!important; }

[HOWTO] Asterisk gegen Hacker absichern

Dieses Thema im Forum "Asterisk Allgemein" wurde erstellt von HobbyStern, 19 Aug. 2010.

  1. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    #1 HobbyStern, 19 Aug. 2010
    Zuletzt bearbeitet: 21 Aug. 2010
    BITTE HIER KEINE ANMERKUNGEN
    DISKUSSIONEN SIND HIER
    . Danke!

    Hallo Gemeinde,

    nachdem ich selber das Opfer wurde, möchte ich hier gerne in schneller Auflistung mit einfachen Schritten bei einem Debian System erklären wie man seinen Asterisk in 30 Minuten sicher macht.

    Wie immer - erhebe ich keinen Anspruch auf Vollständigkeit!

    Um mit einem alten Vorurteil zu brechen - es ist eben vor 3-5 Jahren noch "normal" gewesen Nutzer 10 auch Passwort 10 zu geben, denn "es ist ja eh nur intern genutzt" - wenigstens im privaten Bereich. Wehe dem der sich hier nicht verschätzt, siehe hier.

    Nun gut. Sicherheit in 5 Steps (Digium bescheinigt 7 Steps - aber hier reichen 5 schon sehr aus)

    Schritt 1 - Passwörter absichern

    Auch wenn es "klar" ist - auch interne SIP Telefone sind an einem Asterisk Server von außen zu registrieren - daher - immer brute-force sichere Passwörter verwenden, am besten mit Groß/Kleinschreibung/Zahlen und ggf. Sonderzeichen - nie unter 12 Zeichen.

    Code:
    password=123456789
    
    Süß, besser ist :

    Code:
    password=1a2A3b4B112new
    
    Digium empfiehlt "Make your SIP usernames different than your extensions."

    Schritt 2 - permit/deny Regeln setzen


    Jeder registrierbare Eintrag in der sip.conf kann per permit/deny eingeschränkt werden, ein Beispiel :

    Code:
    [Telefon1-intern]
    defaultuser=10  
    secret=<[URL="http://www.1pw.de/brute-force.html#opt"]ich bin ein starkes passwort[/URL]>
    [B]call-limit=3  [/B]
    [B]contactdeny=0.0.0.0/0.0.0.0                                                                                                                                                      
    contactpermit=10.0.0.0/255.255.0.0[/B]
    
    contactdeny besagt - blocke ALLES
    contactpermit besagt - ausser IP Bereich 10.0.0.x und Subnet 255.255.0.0
    call-limit beschränkt die maximalen Anrufe auf 3 - Hacker werden viele Anrufe gleichzeit machen wollen...

    Schritt 3 - Allgemeine SIP Konfiguration

    Es sollte klar sein das diese Einträge in den Kopf [general] der sip.conf gehören:

    Code:
    [general]
    
    ; *******************************************************
    ;       SICHERHEITSASPEKTE      ANFANG                  *
    ; *******************************************************
    
    alwaysauthreject=yes            ; Wir lassen abgewiesene User nicht wissen DAS es diesen User mit falschem Pwd auch wirklich gibt..!
    allowguest=no                       ; Wir verbieten "Guest" Registrationen, also ohne definierte Anmeldedaten unsererseits.
    
    ; *******************************************************
    ;       SICHERHEITSASPEKTE      ENDE                    *
    ; *******************************************************
    
    EDIT : Hinweis in eigener Sache - Möchte man "anonyme Anrufer" blocken (also Anrufer ohne übertragene Nummer, sog. deaktivierte CLIP-Funktion des Anrufers), befinden wir uns nicht mehr im Rahmen der eigentlichen Sicherheit, wer daran interessiert ist, findet hier Hilfe..

    Das untersagt das es ein Angreifer schafft sich als GUEST zu registrieren und per default Kontext etwas zu unternehmen - authreject gaukelt dem Anfragenden vor das es den Nutzer nicht gibt, wenn er ein falsches Passwort sendet - sehr nützlich um Suchprogramme nicht noch in die richtige Richtung zu lenken!

    Schritt 4 - Make-Up für die extensions.conf

    Der default Kontext sollte zBsp. so aussehen :

    Code:
    [default]
    
    ; Wer hier landet ist entweder schlecht konfiguriert oder hat keine "Rechte"
    
    exten => _X.,1,Answer ()
    exten => _X.,2,Verbose(D E F A U L T ==> ${CALLERID(num)} kam um ${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)} in DEFAULT an als er versuchte die Nummer ${EXTEN} anzurufen.)
    exten => _X.,3,Playback(/dein/weg/zum/benutzerdefinierten/sprachdir/keine_wahlregel)
    exten => _X.,4,Hangup   
    
    
    Was macht dieser Kontext, er loggt in die Asterisk CLI das jemand in den Default-Topf fiel (es kann ja auch mal schlecht konfiguriert worden sein) und spielt die selbsterstellte Ansage "keine_wahlregel" ab...

    Das ist gut.

    Wichtig ist auch der folgende Aspekt, eine kleine Benutzer-Rechte-Verwaltung wie sie seinerzeit betateilchen angepriesen hat und mir somit auch zur Verfügung stellte :

    In der sip.conf bekommt jeder Nutzer einen "Gruppen-Kontext"
    Code:
    [benutzer1]
    user=...
    password=...
    context = Verwaltung
    
    [benutzer2]
    user=...
    password=...
    context = Empfang
    
    In der extensions.conf geben wir der in sip.conf genannten Gruppe einen Kontext und include(n) dort die echten "Rechte" als Kontexte :

    Code:
    [Verwaltung]
    include => anrufbeantworter                     ; Anrufbeantworter abrufen
    include => sub_hints                            ; Standard     
    include => nachtschaltungsfunktionen            ; Die Nachtschaltung steuern
    include => notrufe                              ; Notrufe ermöglichen
    include => intern                               ; Intern telefonieren
    include => mobilfunk                            ; Mobilfunkinetze erreichen
    include => festnetz                             ; Orts- und Fernnetze erreichen
    include => sondernummern                        ; 0180(5), Telefonauskunft,...
    include => international                        ; Auslandsgespraeche fuehren
    
    [Empfang]
    include => intern                               ; Intern telefonieren
    
    Kommt nun ein Hacker in den Genuss das er den Nutzer 2 registriert, kann er nur die erlaubten Funktionen ausführen, also intern telefonieren.

    Es hat aber natürlich auch andere Vorteile (was darf welcher Nutzer) etc.

    Schritt 5 - Auf die stille Treppe! Ban Dich!

    Mit dem GNU Tool Fail2Ban kann man eine schnelle und einfache BAN Situation mit Bordmitteln realisieren.

    Das bedeutet schlichtweg für Asterisk , SSH , FTP etc. können Logfiles automatisiert durchsucht werden, findet Fail2Ban dort das gesuchte (zBsp. Wrong password) wird er mitzählen und den Hacker nach x Versuchen für x Minuten bannen.

    Ich habe es hier in 20 Minuten voll installiert und es mit dem Softphone X-Lite ausprobiert - es funktioniert einwandfrei.

    Das englische Voll-Howto zu diesem Teil gibt es hier. Danke für diese Beschreibung!

    Los gehts. Wir haben DEBIAN, davon gehe ich hier einfach aus und erspare mir die Sources holen und kompilieren zu müssen, in diesem Fall scheint es okay, da folgende Update-Sorgen gebannt :) sind.

    Code:
    apt-get install fail2ban iptables
    
    Sollte die benötigten Pakete holen (inkl. python) und einrichten, SSH ist per default an.

    2. Konfigurieren von Fail2Ban

    Code:
    cd /etc/fail2ban
    nano filter.d/asterisk.conf
    
    Diesen Text am Schluss einsetzen

    Code:
    # Fail2Ban configuration file
    #
    #
    # $Revision: 250 $
    #
    
    [INCLUDES]
    
    # Read common prefixes. If any customizations available -- read them from
    # common.local
    #before = common.conf
    
    
    [Definition]
    
    #_daemon = asterisk
    
    # Option:  failregex
    # Notes.:  regex to match the password failures messages in the logfile. The
    #          host must be matched by a group named "host". The tag "<HOST>" can
    #          be used for standard IP/hostname matching and is only an alias for
    #          (?:::f{4,6}:)?(?P<host>\S+)
    # Values:  TEXT
    #
    
    failregex = NOTICE.* .*: Registration from '.*' failed for '<HOST>' - Wrong password
                NOTICE.* .*: Registration from '.*' failed for '<HOST>' - No matching peer found
                NOTICE.* .*: Registration from '.*' failed for '<HOST>' - Username/auth name mismatch
                NOTICE.* .*: Registration from '.*' failed for '<HOST>' - Device does not match ACL
                NOTICE.* <HOST> failed to authenticate as '.*'$
                NOTICE.* .*: No registration for peer '.*' \(from <HOST>\)
                NOTICE.* .*: Host <HOST> failed MD5 authentication for '.*' (.*)
                NOTICE.* .*: Failed to authenticate user .*@<HOST>.*
    
    # Option:  ignoreregex
    # Notes.:  regex to ignore. If this regex matches, the line is ignored.
    # Values:  TEXT
    #
    
    Nun noch /etc/fail2ban/jail.conf editieren und die folgenden Daten am Ende eintragen :

    Beachte! LOGPATH - muss auf ein Logfile zeigen welches WARNINGs ausgibt!

    Zu verändernde Zeilen in dem folgenden Text :

    LOGPATH=
    SENDER=
    NAME=
    DEST=

    Code:
    [asterisk-iptables]
    
    enabled  = true
    filter   = asterisk
    action   = iptables-allports[name=ASTERISK, protocol=all]
               sendmail-whois[name=ASTERISK, dest=root, [email protected]]
    logpath  = /var/log/asterisk/verbose.log
    maxretry = 5
    bantime = 259200
    
    Am Kopf der Datei findet man einiges was es anzupassen gilt:

    Zu verändernde Variablen in diesem Text :

    IGNOREIP
    DESTEMAIL
    MTA (bei Bedarf)

    Code:
    ignoreip = 127.0.0.0/8 10.0.0.0/8 <meineprivateIPRange>
    destemail = <[email protected]>
    mta = sendmail        / für sendmail oder 
    mta = mail            / für exim (so habe ich es hier
    
    Schaut man sich jail.conf mit Verstand durch ist alles weitgehend erklärt, ich habe die retry von 6 auf 3 herabgesetzt.

    In der logger.conf des Asterisken setzen wir noch :

    Code:
    [general]
    dateformat=%F %T
    
    ein und lassen einen

    Code:
    asterisk -rx "logger reload"
    
    laufen.

    Fertig. Mit iptables --list können wir uns die Regeln ansehen. Zeit für einen Service-Restart :

    /etc/init.d/fail2ban restart

    Nochmals iptables -l sollte nunmehr eine Ausgabe über die bestehenden Regeln geben.

    Hinweis
    Das iptables Paket der Debian Distri ist seit IMHO sid nicht mehr mit einem Init Skript versehen, nach dem was ich hier gesehen habe besteht aber auch kein Bedarf mehr (ändernde Netzwerkadressen machten dies notwendig!) Also kurzum - wir brauchen iptables NICHT zu init.d / starten!
    Hinweis
    Mit der Distri-Installation von fail2ban wurde automatisch fail2ban für ssh installiert , siehe jail.conf


    ENDE

    Das waren die 5 Grundschritte, es gibt sicherlich mehr zu tweaken, aber somit hat unser Asterisk ersteinmal Grundlegende Sicherheitsfunktionen!
     
  2. rmh

    rmh Aktives Mitglied

    Registriert seit:
    6 Juli 2008
    Beiträge:
    1,846
    Zustimmungen:
    6
    Punkte für Erfolge:
    38
    Beruf:
    R&D
    Ort:
    BY
    Hallo Hobbystern,

    zunächst einmal vielen Dank für deine sehr gute Zusammenfassung! :cool:
    Ich frage mich, ob das wirklich so ist. Bisher ging ich davon aus, nur notice sei für fail2ban relevant, während warning optional ist. Bei mir funktioniert das jedenfalls so. Beispiel:

    Auszug aus /etc/asterisk/logger.conf
    Code:
    [logfiles]
    notice        => notice
    
    Auszug aus /etc/fail2ban/jail.conf
    Code:
    [asterisk]
    logpath  = /var/log/asterisk/notice

    Gruß
    R.
     
  3. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    Schau Dir einfach in /etc/fail2ban/filter.d/servicename an - dort findest Du "regex" - welches eine positive Findung benötigt damit Fail2Ban auslöst, würde man dort zBsp. "Remote unix connection" eintragen, so würde bei jedem Asterisk remote Zugriff Fail2ban die passende IP blocken. So wenigstens die Theorie.

    Bei mir zeigt Fail2Ban auf mein "verbose" file namens "stefan.verbose.log"
    Asterisk vermerkt dort :

    "stefan.verbose.log => verbose,notice,warning,error"

    Also darf ich mir etwas aussuchen, es ist auch Schnuppe, Hauptsache Fail2Ban findet die Datei die auch die regex´s enthält wenn es sie braucht um eine Aktion durchzuführen.

    Streng nach dem ersten Unix Gesetzt "Alles ist eine Datei"

    LG Stefan
     
  4. rmh

    rmh Aktives Mitglied

    Registriert seit:
    6 Juli 2008
    Beiträge:
    1,846
    Zustimmungen:
    6
    Punkte für Erfolge:
    38
    Beruf:
    R&D
    Ort:
    BY
    Danke für deine Antwort. :)


    Gruß
    R.
     
  5. rmh

    rmh Aktives Mitglied

    Registriert seit:
    6 Juli 2008
    Beiträge:
    1,846
    Zustimmungen:
    6
    Punkte für Erfolge:
    38
    Beruf:
    R&D
    Ort:
    BY
    Spezielle REGEX für Asterisk 1.8

    Wichtiger Hinweis für Umsteiger: Für Asterisk 1.8 sollte man dringend die asterisk.conf von fail2ban überarbeiten! Asterisk 1.8 schreibt nun IPAdresse:port ins Log. Beispiel siehe hier: http://www.fail2ban.org/wiki/index.php/Talk:Asterisk


    Gruß
    R.
     
  6. dadooronron

    dadooronron Neuer User

    Registriert seit:
    5 Dez. 2012
    Beiträge:
    3
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #6 dadooronron, 5 Dez. 2012
    Zuletzt bearbeitet: 5 Dez. 2012
    Von mir auch ein Hinweis zu Asterisk 1.8:

    Bei bestimmten Angriffen (wenn man nicht INVITE oder REGISTER zum Server sendet, sondern OPTIONS) erscheinen folgende Einträge im Log:

    [2012-12-05 13:39:05] NOTICE[3914] chan_sip.c: Sending fake auth rejection for device "123" <sip:[email protected]_OWN_IP>;tag=B2ymjXmK01Qvr

    [alwaysauthreject=yes muss dafür in sip.conf gesetzt sein.]

    Hier wird leider nicht die Angreifer-IP genannt, sondern nur die eigene ! Zu dem Thema hat sich bei den Asterisk Entwicklern seit 3 Jahren (!) nichts getan ! Wenn man hier nicht vorausschauend "ignoreip" gesetzt hat, blockt man sich selbst.

    Wer seinen Asterisk also zum Internet hin öffnet, sollte die Finger von 1.8 lassen, wenn man "nur" fail2ban einsetzt ...

    Über Widerspruch würde ich mich freuen :D