Hacker in meinem Asterisk Server

[rentier-s]

Hier geht es um die technischen Aspekte, nicht um Mutmaßungen über den Erfolg einer Anzeige. BTT bitte.

 

[shadow01]

Hallo zusammen

Ich habe in den letsten paar tage auch relativ oft Hackversuche erlebt. Sie konnten jedoch abgewehrt werden so das kein Schaden entstand.

Was ich aber etwas seltsam finde ist, in der sip.conf habe ich deny 0.0.0.0/0.0.0.0 und permit 192.168.0.0/255.255.255.0 wieso aber kann ich mich von meinem zweiten WAN port einlogen?

[general]
language=de
bindport=7010
deny=0.0.0.0/0.0.0.0	
permit=192.168.0.0/255.255.255.0
;bindaddr = 80.xxx.yyyy.zzz		;nur wenn der Server direkt im Netz stehet
bindaddr=0.0.0.0
context = waehlplan
rtpkeepalive=5
externrefresh=180
useragent=portasipfriendly
allowguest=no
qualify=yes
insecure=port,invite
canreinvite=no
nat=yes				;wurde im internen Netz aktiviert 28.7
videosupport=yes
t38pt_udptl=yes

disallow=all
allow=ulaw
allow=g729
allow=gsm
allow=h263
allow=h264

tos_sip=cs3
tos_audio=ef
tos_video=af41

externip=xyz.dyndns.org
localnet=192.168.0.0/255.255.255.0

jbenable=yes
;jbforce=yes
;jbmaxsize=200
jbimpl=adaptive
;jbtargetextra=40
;jblog=yes

Logeintrag:

100/100                   192.168.0.1                              D   N             7010     OK (73 ms)
101/101                   46.xyz.xyz.xyz                          D   N             5060     OK (73 ms)

Wieso wird hier eigentlich das eine Telefon welches an einem anderen WAN hängt mit 5060 eingelogt und nich wie in der sip.conf eingestellt mit 7010

Gruss und danke im voraus

 

[IEEE]

Was ich aber etwas seltsam finde ist, in der sip.conf habe ich deny 0.0.0.0/0.0.0.0 und permit 192.168.0.0/255.255.255.0 wieso aber kann ich mich von meinem zweiten WAN port einlogen?

permit/deny funktionieren meiner Erfahrung nach nur in der Device Konfiguration, nicht in der Global Sektion.

Wieso wird hier eigentlich das eine Telefon welches an einem anderen WAN hängt mit 5060 eingelogt und nich wie in der sip.conf eingestellt mit 7010

An der Stelle wird AFAIK der Port angezeigt den das Endgerät seinerseits benutzt und nicht Dein eigener.

 

[shadow01]

Hallo Michael

Danke für deine Antwort! Habs gerade versucht und gesehen das wenn ich permit/deny bei den users hinterlege ich wirklich ausgesperrt werde. Da wäre ich nicht drauf gekommen! Danke

könnte in der extensions.conf die folgende Änderung als eine Art Passworteingabe für etwas mehr sicherheit sorgen?

bis anhin:
[externL1]
exten => _[0123456].,1,Dial(SIP/${EXTEN}@Provider_out1)

neu so:
[externL1_portable]
exten => _8608[0123456].,1,Dial(SIP/${EXTEN}@Provider_out1)

Gruss Franky

 

[HobbyStern]

Hi shadow,

ich mache es mittlerweile so, dass ich "dubiose" Vorwahlen/Länder bzw. Sondernummern mit einer kleinen Frage auf deutsch spicke, irgendwas sehr einfaches - was aber nicht jemand kennen kann der noch nie vor Ort war. Permit/Deny ist netzwerktechnisch natürlich grandios um die Spinner abzuwehren.

BTW --> Mein Fail2Ban bemerkt in den letzten Tagen SEHR starken Andrang auf den Server, Bans am laufenden Ban-de. Ist mächtig druck da draussen bei den Jungs...

Grüsse! Stefan

 

[Antimon]

Hallo zusammen,

auch ich muss mich outen... um zukünftig aber keine Probleme mehr zu bekommen, bin ich dabei, mir einen Bayes-Filter zu implementieren.
Das läuft wie folgt ab: Alle ausgehenden Anrufe werden durch ein PHP-AGI-Skript geprüft und verschiedene Punkte vergeben. Beispielsweise werden Gespräche ins Ausland mit einer höheren Punktzahl bewertet als innerdeutsche Festnetz-Gespräche. Dann wird geprüft, wann die Anrufe stattfinden (nachts gibts zusätzliche Punkte), ob die gleiche Rufnummer in einem bestimmten Zeitraum wiederholt gewählt wurden, etc.
Ab einer bestimmten Punktezahl muss ein Kennwort eingegeben werden, um raustelefonieren zu können, wird eine noch höhere Punktezahl erreicht, wird das Gespräch abgewiesen.

Derzeit ist folgendes implementiert:
- Welche Rufnummer wird angewählt (Inland, Handy, Sondernummer, Ausland)?
- Wann wird telefoniert?
- Wie oft wurde die Zielnummer innerhalb der letzten X Minuten angerufen?
- Wie oft wurden innerhalb der letzten X Minuten von der abgehenden Nummer telefoniert?

Ich denke dass dieser Schutz recht zuverlässig greifen sollte, oder sieht jemand irgendwo Schwierigkeiten? Habt Ihr noch Ideen, was man noch als Bewertungskriterien verwenden könnte? Die Daten der Gespräche kommen übrigens aus der MySQL-CDR-Datenbank.

Ach ja - meinen Asterisk habe ich natürlich auch mit den hier im Forum angeführten Schutzmaßnahmen ausgestattet... nur dass nicht jemand denkt, das wäre mein einziger Schutzmechanismus....

 

[inovatoor]

Damn, bei uns war auch jemand im System. Allerdings hab ich noch nicht rausgefunden wir er das geschafft hat.
Erst hat er es via Brute Force gegen ssh mittels immer wechselden Ports und Usern versucht, zum Glück ohne Erfolg.
Anschließend hat er verschiedene SIP User probiert. Asterisk hat es da natürlich mal wieder nicht geschafft die fake rejection zu senden. Und als er dann einen getroffen hat, bekam ich nur einmal die Meldung:
- Wrong password
Direkt danach hat er sich alle CAPI Channel geschnappt, ohne das der Peer angemeldet gewesen wäre und konnte fleißig in allen Kontexten rumspielen.
Außerdem konnte er trotz dynamischer IP wiederkommen, das gibt so den Hauch von Insider Job...

Das absolut ärgerliche ist nicht, dass es jemand geschafft hat obwohl ich ALLE Sicherheitsmechanismen, die hier erwähnt wurden implementiert habe, incl. einer Intrusion Detection, die in den IP Tables sperrt.

Es ist zum heulen!

 

[HobbyStern]

Hört sich wirklich nach einem gezielten Angriff an, woher kommt/kommen die IP/s?

Erst hat er es via Brute Force gegen ssh mittels immer wechselden Ports und Usern versucht, zum Glück ohne Erfolg.

fail2ban hat auch ssh support, kennst Du den?

Anschließend hat er verschiedene SIP User probiert. Asterisk hat es da natürlich mal wieder nicht geschafft die fake rejection zu senden.

Welche Version von * und warum gab es keine Logmeldungen für fail2ban?

Und als er dann einen getroffen hat, bekam ich nur einmal die Meldung:
- Wrong password

Frage : Wie sicher sind die Passwörter? Sehr leicht zu erraten? Wenn der zweite BruteForce Name sitzt ist das anzunehmen..

Direkt danach hat er sich alle CAPI Channel geschnappt, ohne das der Peer angemeldet gewesen wäre und konnte fleißig in allen Kontexten rumspielen.

Das ist dann auch wieder eine Einstellungssache, Peers ohne Registrierung kann man ja gesondert behandeln.

Außerdem konnte er trotz dynamischer IP wiederkommen, das gibt so den Hauch von Insider Job...

Ich muss ehrlich sagen ich verstehe das nicht so ganz - wie lange hat er das denn versucht? IMHO wird eine IP ja priater Natur alle 24h erneuert...

Vielleicht solltest Du Dir dann einmal weiterführende Tools und Konfigurationen ansehen - tripwire als Fallstrick gegen SSH Eindringle zBsp. oder mit etwas mehr Zeit SNORT - die Asterisk Sicherheitshinweise findest Du am Anfang dieses Artikels, etwas mehr Präsentationstechnisch ist auch hier ein PDF.

Wenn Du möchtest würde ich mich hier über ein LOG der relevanten Zeiten kurz vor bis nach Austritt des Angreifers freuen...

Ich muss ehrlich sagen, es liest sich wie ein 08/15 Angriff auf ein schlecht gesichertes System...

Grüsse und Kopf Hoch!

Stefan

 

[inovatoor]

[Feb 5 07:10:24] NOTICE[886] chan_sip.c: Call from 'anderernutzername' to extension '900972592581502' rejected because extension not found.
[Feb 5 07:19:46] NOTICE[886] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.8.16.175' - Wrong password
[Feb 5 07:20:00] NOTICE[886] chan_sip.c: Call from 'anderernutzername' to extension '900972592995047' rejected because extension not found.
[Feb 5 07:20:06] NOTICE[886] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.8.16.175' - Wrong password
[Feb 5 07:20:47] NOTICE[886] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.8.16.175' - Wrong password
[Feb 5 07:21:42] WARNING[4508] app_dial.c: Unable to create channel of type 'CAPI' (cause 44 - Requested channel not available)
...

<-- ab da hat er dann telefonieren können, und ja; das Log startet tatsächlich mit Call from extension, da hatte er vorher nichts anderes angeworfen, er hat zwar vorher direkt eine fake auth provoziert auf einen anderen Nutzernamen, aber das war es. Da hätte meine intrusion detection greifen müssen, hat sie aber nicht (ist eine pearl Lösung, die manchmal versagt), allerdings sind davor auch nur fünf verschiedene Nutzer die er probiert.

Bitte nicht böse sein, falsch ich etwas zynisch klinge, jedoch

ich wehre mich gegen den Vorwurf, der schlechten Sicherung.
Aber wenn sich eine IP nach drei Anläufen registrieren kann, dann findet das keine Intrusion detection, nicht wenn ich die Möglichkeit haben will mich beim Passwort eintippen auchmal zu vertippen. Evt. muss ich aber das Ding doch noch schärfer stellen...

Peers ohne Registrierung dürfen gar nichts, die Passwörter sind sehr wohl sicher, außerdem scheint das Passwort ja nicht zu sitzen (nach einer Stunde bekomm ich einmal die Meldung Wrong password, dann nochmal eine stunde später), er konnte nur einfach plötzlich über 'anderernutzername' auf nen anderen Kontext zugreifen. Peers ohne Registrierung, dürfen eigentlich gar nichts, es gibt keine guests, es gibt immer fake auth rejects, default context läuft via wildcards bei jeder extension ins leere, die Passwörter sind nicht semantisch, und eine Mischung aus klein, groß, Zahlen, etc.
Wie ich bereits erwähnte: ich hab die ganzen Tipps und Tricks zum Absichern auch gelesen und es ist nicht der erste Angriff und bisher haben immer ALLE Sicherheitsmaßnahmen gleichzeitig gegriffen. Auch die Links erzählen mir deshalb nichts neues, das hab ich alles eingebaut.

Ich kann nicht mehr machen, als das alles umsetzen, testen wenn es dann über Monate im Produktivbetrieb läuft bin ich eben doch etwas stutzig, wenn ganz plötzlich aus heiterem Himmel sich jemand Unbekanntes so Zugang verschafft.

 

[tifa]

inovatoor das ist zu wenig info für uns

welche BS
welche atserisk
wie sieht dein sip.conf und extensions.conf aus
hast du fail2ban ?

 

[dg7feq]

[Feb 5 07:20:00] NOTICE[886] chan_sip.c: Call from 'anderernutzername' to extension '900972592995047' rejected because extension not found.

Oh, der gleiche scheint bei mir auch schon seit 2 Wochen erfolglos reinzukommen, jedenfalls geht der Testanruf auch immer auf israelische Handynummern (sogar genau die gleiche Nummer ist dabei...). Mein asterisk hat allerdings nur eingehende Wahlregeln und ist daher selbst im Erfolgsfall für den Hacker recht nutzlos.

 

[inovatoor]

Ist ein Lucid Lynx Ubuntu, ist Asterisk 1.6.2, ich nutze kein Fail2Ban, sondern eine Intrusion Prevention im Router und lese /log/asterisk/messages aus und sperre verdächtige Ips (fake auth, wrong password, no matching peer).

In der sip.conf steht

[general]
port=
bindport=
context=telefone
binaddr=0.0.0.0
disallow=all
allow=gsm
allow=ulaw
allow=alaw

localnet=192.168.x.x/255.255.255.0
externhost=unbekannt
externrefresh=10
nat=yes
insecure=invite
qualify=yes

allowguest=no
alwaysauthreject=yes
registerattempts=20

maxexpirey=240
defaultexpirey=240

;die peers sehen so aus
[peer]
type=friend
context=der eigentliche context mit den peers
secret=
host=dynamic
username=username
canreinvite=no
port=
dtmfmode=rfc2833

die extension.conf steht

[default]
exten => _X.,1,Goto(vm-intro,${5000},1)

[telefone]
exten => _X.,1,Goto(vm-intro,${5000},1)

[der eigentliche context mit den peers]

;hier darf auch auf die capi channel zugegriffen werden

 

[HobbyStern]

Bevor wir anfangen, ja - WhoIs sagt der kommt aus Gaza und ist somit ganz sicher kein Insider oder sowas - er ist einfach ein BruteForce-Bot.

address: Palestinian Internet Services
address: P. O. BOX 5111 Gaza City, Palestine

Ich fange mal der Reihe nach an.

Vorschläge:

- Benutze fail2ban, besser snort - es MUSS ein daemon sein und nicht ein cronjob, Hintergrund ist einfach, der Dämon merkt live das jemand einbricht, der Cron halt zur Planzeit...Konfigs findest Du im Schwesternbeitrag von mir.
- Sichere Deine Peers nach Anwendungsschema, d.h. frage Dich welches zBsp. Telefon wo liegt und wie es agieren muss.

Ein Telefon in einer stationären Umgebung, welche durch eine FW von der Welt abgeschirmt ist - ist sehr leicht zu sichern.
Unter der Annahme das DEIN Netzwerk 10.0.0.x hat und die "Welt" alles andere hilt Dir das hier immens

[eintelefon-lokal]
...
contactdeny=0.0.0.0/0.0.0.0
contactpermit=10.0.0.0/255.255.0.0
call-limit=2

Call-Limit habe ich hier eingeführt um einen GAU abzumildern, es verhindert das der Brute-Forcer dann auch einhundert Gespräche führen kann, aber so weit wollen wir es ja gar nicht erst kommen lassen...

- Sichere außenstehende Server, mit welchen Du kommunizierst separat ab, am Beispiel von bluesip mit der Range 217.74.179.x

contactdeny=0.0.0.0/0.0.0.0
contactpermit=217.74.179.0/255.255.0.0

Ich muss einwerfen das ich hier und auch an anderen Servern noch nie eine CAPI Konfiguration benutzt habe - das Einfallstor sehe ich jedoch bei SIP.

In der extensions.conf unter general solltest Du einiges hinzufügen :

extenpatternmatchnew=no
context=INVALID
userscontext=default

INVALID verhindert genau dieses Szenario welches hier anscheinend auftrat - invalid sieht dann so aus :

[INVALID]                                               ; Hier kommen Leute hin die nicht registrieren duerfen !
exten => s,1,Answer            
exten => s,2,Playback(/var/www/ansagen/invalid1)       
exten => s,3,Hangup()

Um in diesem Fall zu bleiben (Ghaza) - hinterfrage Deinen Dialplan, wohin telefonierst Du?
Ich habe immer den Kontext "sondernummern" dabei und da dieser SEHR SELTEN in Frage kommt habe ich eine kleine Sicherheitsfrage vorangestellt die jemand aus Ghaza, Ruanda oder sonstwo nicht beantworten kann...mal ganz nebenher sichere ich auch dann sofort den Anruf bzw. dessen Inhalt...

[sondernummern]                                                 ; Sondernummern abfangen

exten => _0800.,1,Set(ZIELNR=${EXTEN})
exten => _0800.,n,Set(MIXMONITOR_FILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${EXTEN}-SONDERNUMMER-VON-${CALLERID(num)})
exten => _0800.,n,Monitor(wav,${MIXMONITOR_FILENAME},m)
exten => _0800.,n,Goto(sondernummern,s,1)

exten => _01[8-9].,1,Set(ZIELNR=${EXTEN})
exten => _01[8-9].,n,Set(MIXMONITOR_FILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${EXTEN}-SONDERNUMMER-VON-${CALLERID(num)})
exten => _01[8-9].,n,Monitor(wav,${MIXMONITOR_FILENAME},m)
exten => _01[8-9].,n,Goto(sondernummern,s,1)

exten => _0900.,1,Set(ZIELNR=${EXTEN})
exten => _0900.,n,Set(MIXMONITOR_FILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${EXTEN}-SONDERNUMMER-VON-${CALLERID(num)})
exten => _0900.,n,Monitor(wav,${MIXMONITOR_FILENAME},m)   
exten => _0900.,n,Goto(sondernummern,s,1)  

exten => s,1,NoOp()
exten => s,2,Set(NUMINVALID=0)       
exten => s,3,Set(NUMTIMEOUTS=0)
exten => s,4,Background(/var/www/ansagen/international)    
exten => s,5,Set(TIMEOUT(digit)=5)   
exten => s,6,Set(TIMEOUT(response)=10)
exten => s,7,WaitExten(2)

exten => t,1,Set(NUMTIMEOUTS=$[${NUMTIMEOUTS}+1]})
exten => t,2,Gotoif($["${NUMTIMEOUTS}" < "2"]?:s,3)            
exten => t,3,Background(vm-goodbye)                      
exten => t,4,Hangup()

exten => i,1,Set(NUMINVALID=$[${NUMINVALID}+1]})
exten => i,2,Gotoif($["${NUMINVALID}" < "2"]?:10)
exten => i,3,Background(invalid)
exten => i,4,Goto(s,3)               
exten => i,10,Playback(vm-goodbye)
exten => i,11,Hangup()

exten => <die Zahl welche die Antwort ist>,1,Goto(isdn_ausgehend,${ZIELNR},1)                         ; Tippfehler oder int.Anruf     (Ausland)

Aber auch das brauchen wir ja eigentlich nicht, da der Daemon von Snort oder fail2ban sowas ja eigentlich immer verhindert.

mM nach ist das WICHTIGSTE (!) das man die Apparate etc. eben nicht so wie in zahlreichen Grundkursen von Asterisk verwendet der Reihe nach nummeriert, also NICHT 10,11,12 und dann idealerweise noch das Passwort 10,11,12 sondern zBsp. 10peter,11buero.. usw usf und vielleicht das Passwort Pet10geheim,buero11abstrakt...

Damit solltest Du schon besser liegen. Als ich damals den Thread "Hacker in meinem Server" eröffnet habe (schau mal nach) war meine Konfiguration auch noch gut und sauber, aber halt anfällig und leicht zu verstehen.

Ich will NICHT sagen das Deine einfach ist, Sie scheint nur nicht sicher (genug) gewesen zu sein. Ghaza hat auch schon hier angeklopft - so sagen es meine Logs...jedoch hat mein Snort Ghaza nach Hause gesandt

Solidarisieren wir uns mal - auch ich bin gehackt worden, jedoch habe ich daraus gelernt und gebe es nun gerne weiter!

LG Stefan

 

[inovatoor]

Das Problem besteht doch genau darin, dass Telefone nicht so gesichert werden können. Die liegen auf Rechnern oder hängen an ATAs hinter einfachen dynamsichen IPS. In meinem Fall ALLE.
Deshalb ist auch kein IAX möglich, weil ich damit kein Analoges Telefon oder eine ISDN Anlage anklemmen kann ohne gleich wieder einen extra Rechner hinstellen zu müssen.

Die Passwörter sind nicht mal in annähernd in Gestalt von Pet10geheim, das ist nämlich immer noch innerhalb weniger Minuten zu knacken.
Außerdem woher die Meldung wrong password, wenn er das genackt hätte?

In meiner extension steht auch ein general context. Das war auch definitv nicht das Problem, an eben diesem Pen-Versuch sind ja schon extrem viele andere bei mir gescheitert. Deshalb ist mein Problem gerade': wie kam er überhaupt rein.
Deshalb nochmal alles zusammenfassend:

Intrusion detection hat nicht funktioniert, weil er direkt einen Peer getroffen hat.

INVALID verhindert genau dieses Szenario welches hier anscheinend auftrat - invalid sieht dann so aus :

Guest Zugänge gibt es keine, nur die registrierten Peers kommen in den ausgehenden Kontext. In meinem default Kontext war er nie! Das war definitiv nicht der Angriffspunkt :evil:
Laut logs hat er telefoniert ohne sich anzumelden, kann SIP ja.

Die User haben alle Ihren Kontext der festlegt was sie dürfen.

 

[HobbyStern]

Nabend zurück!

Vorweg - no need to feel abused! Ich will Dir nix!

Das Problem besteht doch genau darin, dass Telefone nicht so gesichert werden können. Die liegen auf Rechnern oder hängen an ATAs hinter einfachen dynamsichen IPS. In meinem Fall ALLE.

Nimm doch eine einfache Range an IPs die für den DHCP möglich sind - es wird ja immernoch verhindern das die IP zBsp.
DENY = 0.0.0.0
ALLOW = 192.168.0.x

Jede IP die vom DHCP vergeben wurde - wird gut sein und durchgehen 31.2.65.72 wird nichts machen können (aber natürlich nur in Verbindung mit einer Anmeldung)

Außerdem woher die Meldung wrong password, wenn er das genackt hätte?

Die Meldung kommt meist vorher. Ein Beispiel :

Richtiges PWD 114
00:01 Wrong Password "112"
00:02 Wrong Password "113"
00:03 Anruf wird getätigt (so würde es ohne genügenden Verbose-Output aussehen)

Wenn der nächste Cronjob des zBsp. Fail2ban erst um 00:05 läuft dann wird erst um 00:05 verhindert das dieser Angreifer arbeitet - und auch dann nur solange bis die Blockade wieder behoben ist (IMHO per default nur 10 Minuten..besser ist ne Stunde oder einen Tag)

Bist Du Dir SICHER das sich der Bruter nicht registriert hat? Wie hoch steht Dein Verbose/Debug? Würde ein REGISTER bzw. ein erfolgreicher Anmeldeversuch angezeigt?

Gib mir doch bitte mal den Inhalt Deiner logger.conf

[logfiles]
stefan.fehler.log => error
stefan.warnungen.log => warning
stefan.verbose.log => verbose,notice,warning,error
console => notice,warning,error

Beispielhaft....

Laut logs hat er telefoniert ohne sich anzumelden, kann SIP ja.

Aber nur wenn Du es erlaubst! IMHO kann er ja ohne REGISTRIERUNG und ohne guestallowed=yes nicht weiter...

EDIT: Recht hast Du, es gibt wirklich den Eintrag bei Dir :

alwaysauthreject=yes            ; Wir lassen abgewiesene User nicht wissen DAS es diesen User mit falschem Pwd auch wirklich gibt..!
allowguest=no                   ; Allow or reject guest calls (default is yes)

Dann würde ich wirklich darum bitten das Du schaust ob Du ein gesprächigeres Log erzeugen lässt...

LG Stefan

 

[IBM-FAN]

Evt. muss ich aber das Ding doch noch schärfer stellen...

Ist mir gestern Abend auch passiert. Einmal "wrong password" dann war er drin. Und die Passworte sind lang. Zum Glück hat er einen Peer erwischt, der Ausland ins "invalid" schickt. Und ich habe es zufällig zeitnah gesehen, so dass er keine anderen Peers testen konnte. Wie trifft man im zweiten Versuch ein 12-stelliges Passwort? Will mir nicht in den Kopf.

Allenfalls blieb mir nichts anderes übrig, als das Jail so scharf zu stellen, dass Passworte beim ersten mal stimmen müssen.

 

[HobbyStern]

gesprächigeres Log

Hast Du denn da ggf. mehr Output?

im zweiten Versuch ein 12-stelliges Passwort?

IMHO gar nicht...

Welche 1.6er Version nutzt Du? Patches im SIP?

BTW (EDIT) : Es gibt dieses BruteForce Programm auch als legalen OpenSource Download - damit kann man sein eigenes System einfach mal testen....

 

[ktw2003]

Frage in die Runde, ggf. habe ich es auch überlesen. Mache ich was falsch oder ist dies ein Bug bei Verwendung von IPv6? In meiner Konfiguration ist überall ([general] und [nebenstelle]) deny und permit auf die jeweilige IP gesetzt. Meldet sich jetzt ein SIP-Teilnehmer über IPv4 an und die IP-Adresse stimmt nicht, so schlägt die ACL entsprechend zu und die Anmeldung wird wie gewünscht abgewiesen. Verwendet die Gegenstelle aber IPv6, so wird das "deny=0.0.0.0/0.0.0.0" einfach ignoriert und man kann ich von jeder beliebigen IPv6-Adresse aus anmelden!!

Es wird Asterisk Version 1.8.20.1 mit IPv6 ("bindaddr=[::]:XXXX") verwendet.

 

[HobbyStern]

Google Treffer auf den Digium Servern :

>> deny=ipv4,0.0.0.0 
>> deny=ipv6,0::0    ; Just deny all IPv6, but allow IPv4 
> You shouldn't have to specify "ipv4" or "ipv6" in the config file. It's 
> easy to distinguish between the two types based on just the address itself.

EDIT : Hier ist es genauer ausgeführt

 

[ktw2003]

Hätte ich vermutlich dazu schreiben müssen, aber auf der Seite war ich zuvor auch schon und habe diese diversen Verschläge probiert, leider alle ohne die gewünschte Wirkung. Daher habe ich die Hoffnung, dass hier jemand dabei ist, der dies bereits selber implementiert hat.