Depuis quelques semaines, avec plusieurs administrateurs de serveurs Asterisk nous constatons une évolution de tentatives d’attaques sont tentées chaque jours sur nos infrastructures. Ce sont des attaques de type ‘bruteforce’. Surement du à l’euphorie des vacances scolaires, nous avons répertorié une augmentation de 400% du nombre d’attaques/jours, soit 15-20 adresses IP bannies/jours et quelques mégas de traffic plombé 
Messages étiquettés Asterisk
Asterisk : Protégez-vous !
sept 5
Dans un précédent article j’ai présenté comment protéger son serveur des attaques bruteforce avec l’aide de fail2ban. Comme décrit dans cet article de nos jours, il est très important de se protéger de ce type d’attaque et c’est pourquoi dans ce billet je vais vous montrer comment protéger un serveur asterisk avec fail2ban en une dizaine de minutes au maximum.
Lire le reste de cet article »
Plusieurs personnes sont ou ont étés confrontées à ce problème. Lorsque vous ajoutez les lignes pour permettre à un correspondant extérieur de vous joindre et de lui balancer une musique d’attente (à la manière normale diront nous) votre correspondant aura un silence morbide jusqu’au moment ou vous allez décrocher ou qu’il tombe sur le répondeur. Voici la solution pour balancer votre musique de pré-décroché :
Dans votre fichiers extensions.conf (et dans le context d’arrivée):
exten => ovh23,1,Ringing exten => ovh23,2,Wait(1) exten => ovh23,3,Answer() exten => ovh23,4,StartMusicOnHold(predecro) exten => ovh23,5,PlayBack(/usr/share/asterisk/sounds/silence/1) exten => ovh23,6,Dial(SIP/100&SIP/101,20,tTm(predecro)) exten => ovh23,7,Voicemail(100) exten => ovh23,8,HangUp() |
Explications : ça sonne, vous attendez 1 seconde, vous répondez, vous démarrer la musique d’attente qui correspondant à la classe de la musique de prédécroché, vous jouez un silence d’une seconde (fichier fourni avec asterisk). Vous faites sonner vos postes avec le paramètre m(classe_moh) …
Le chemin vers les sons asterisk peut être différent selon votre distribution
Bad request Protocol Paquet
jan 11
Lorsque vous connectez un asterisk à OVH, vous avez sûrement cette ligne qui pourri vos logs :
[Dec 1 18:01:59] WARNING[26531]: chan_sip.c:6499 determine_firstline_parts: Bad request protocol Packet
Pour résoudre ce soucis, tapez cette commande :
# iptables -A INPUT -p udp -m udp --dport 5060 -m string --string "Cirpack KeepAlive Packet" --algo bm --to 65535 -j DROP
