PDA

Voir la version complète : Sécurité



kuusou
05/05/2013, 15h29
Bonjour,

Je m'apercois en analysant les logs du 'message' logfile que j'ai une avalanche de connections tentées sur mon serveur.

[May 5 15:08:20] NOTICE[15301] chan_sip.c: Call from '' (188.165.236.181:5088) to extension '972599532957' rejected because extension not found in context 'incoming'.

Dans cette ligne il s'agit d'une IP, mais je dirais que j'en ai déjà un grosse série différentes. Certaines reviennent de manière incessante.

J'ai installé fail2ban, mais j'ai du me craker sur un parametrage car cela continue de plus belle.

Mes questions sont :
1- Est ce normal, et tout le monde expériment'il des cascades de tentatives de log ?
2- Fail2ban n'est il pas sensé bloquer les IP qui tentent en boucle de se connecter, si oui doit je créer un filtre spécial pour fail2ban ?
3- L'encryption du mdp est il un moyen efficace d'éviter les bruteforce ? (a noter que le serveur est un serveur dédié, déporté de mon lan).
4- Tous les tutos et toutes les info que j'ai lue à ce sujet datent pour la plupart de 2006-2011. Asterisk est il plus fiable en sécurité qu'il y a 5 ans, où cela mérite t'il que je mette un spécialiste sur le sujet ?

J'espérais que tout serait blindé dès le départ mais je pense que j'ai vu un peu trop le projet façon 'Happy World" !

Merci pour tous les réponses que vous saurez ou voudrez bien m'apporter

jean
06/05/2013, 03h21
- vérifier allowguest=no dans sip.conf

- lire README-SERIOUSLY.bestpractices.txt dans le répertoire de download d'asterisk

kuusou
06/05/2013, 04h12
Merci pour votre réponse, j'en suis arrivé à la même conclusion après tout ce temps de lecture.

Pour autant je bloque désormais sur l'étape suivante :
NOTICE[5295] chan_sip.c: Sending fake auth rejection for device 444<sip:444@xx.xx.xx.xx>;tag=6e3dd121

Pas d'IP apparente, donc pas de solution de blocage ?

Merci en tout cas d'avoir pris la peine de répondre.

jean
06/05/2013, 04h21
déjà, le pirate n'arrive plus a essayer de passer un appel - il est jeté avant, c'est un progres.

sur le fail2ban et fake auth: http://forums.asterisk.org/viewtopic.php?f=1&t=74947&start=0&hilit=fail2ban+fake+auth

sinon, sur ce forum:
http://www.asterisk-france.org/showthread.php/1967-Question-sur-la-s%C3%A9curit%C3%A9-encore-et-toujours?highlight=iptables
http://www.asterisk-france.org/showthread.php/814-securisation-d-une-installation-asterisk?highlight=iptables

kuusou
06/05/2013, 11h05
Merci pour cette réponse !
Du coup je suis en train de ramener la dernière version, je v recompiler et voir si cela corrige naturellement la problème.
Si ce n'est pas le cas, j'ajouterai les modifications proposées par le lien 1 que vous m'avez donné.
J'espère que cela va fonctionner !

kuusou
12/05/2013, 02h52
J'ai testé de procéder comme le suggérait le post que tu as cité Jean, mais je ne suis pas parvenu à trouver le code source dans le fichier chan_sip.c
Je pense (sauf erreur de ma part) que ce fichiers a subit de nombreuses modifications depuis l'année de rédaction du post en question.

Pour autant, j'ai eu beau passer à la version 1.8.21, j'ai toujours des essais de connexions que je n'arrive pas à contrôler (environ une trentaine par jour).
En voici un exemple:

[May 12 01:52:24] NOTICE[3862] chan_sip.c: Failed to authenticate device 202<sip:MONSERVEURASTERISK>;tag=1f7b569c
Ai je mal paramétré quelque chose pour que l'ip impliquée soit celle de mon serveur asterisk ? Dans le cas où c'est normal, comment récupérer les IP qui font du forcing pour les loguer, et mettre une règle en place avec fail2ban ?

Merci de vos réponses !

jean
13/05/2013, 14h41
je pense que le hacker met intentionnellement dans le from ton ip, sachant que nombreux serveurs répondent sur l'@ d'origine et pas celle du protocole à cause du nat.

il te faut prendre le fichier channels/chan_sip.c, rechercher toutes les chaines 'Failed to authenticate device ", doubler cette ligne en mettant:

ast_log(LOG_NOTICE, "IPFailed to authenticate device %s\n", ast_sockaddr_stringify_addr(addr)));

et configurer F2B pour chopper le messge IPFailed...

kuusou
13/05/2013, 22h55
Je regarde cela de suite !
Voila le code original de mon chan_sip.c, ce code est présent 3x fois.

ast_log(LOG_NOTICE, "Failed to authenticate device %s\n", get_header(req, "From"));

J'y ai fait succéder
ast_log(LOG_NOTICE, "IPFailed to authenticate device %s\n", ast_sockaddr_stringify_addr(addr)));

...en ayant pris l'initiative de retirer une des parenthèses de fermeture de fin (j'avais un message d'erreur à la compilation^^)

Je reviens vers toi dès que j'ai testé :)

------------------- >> Edit du post

L'ip est donc parfaitement détectée, grand merci Jean !
Je passe à la création de la regle sous fail2ban.

Voici mon code (du moins sur la partie failregex)


failregex = NOTICE%(__pid_re)s .*: Registration from '.*' failed for '<HOST>' - Wrong password$
NOTICE%(__pid_re)s .*: Registration from '.*' failed for '<HOST>' - No matching peer found$
NOTICE%(__pid_re)s .*: Registration from '.*' failed for '<HOST>' - Username/auth name mismatch$
NOTICE%(__pid_re)s .*: Registration from '.*' failed for '<HOST>' - Device does not match ACL$
NOTICE%(__pid_re)s .*: Registration from '.*' failed for '<HOST>' - Peer is not supposed to register$
NOTICE%(__pid_re)s .*: Registration from '.*' failed for '<HOST>' - ACL error (permit/deny)$
NOTICE%(__pid_re)s <HOST> failed to authenticate as '.*'$
NOTICE%(__pid_re)s .*: No registration for peer '.*' \(from <HOST>\)$
NOTICE%(__pid_re)s .*: Host <HOST> failed MD5 authentication for '.*' (.*)$
NOTICE%(__pid_re)s .*: Failed to authenticate user .*@<HOST>.*$
NOTICE%(__pid_re)s .*: Failed to authenticate user .*@<HOST>.*$
NOTICE%(__pid_re)s .*: IPFailed to authenticate device <HOST>



J'ai ajouté la dernière ligne, mais je ne suis pas sur de la syntaxe? Peux tu me dire si cela te semble correcte ?

Merci infiniment en tout cas !

jean
24/05/2013, 04h30
dsl, j'avais un peu raté la réponse.... j'ai regardé plus en détail ( un couillon est venu me chercher des noises...) et en fait, cette solution marche (ta syntaxe f2b semble bonne, tu peux valider avec fail2ban-regex en n'oubliant pas de relancer le service une fois que c'est ok)

mais y'a plus simple... sur les dernières versions d'asterisk, sur à partir de la 10, peut etre avant, il y a un nouveau mot clé pour le module logger - il faut ajouter dans logger.conf un ,security à la ligne console et message => et là tous les détails apparaissent... il reste à adapter le filtre f2b !! mais là, on monte d'un cran dans la sécurité, sans modifier le source !

olppp
24/05/2013, 12h01
Bonjour,

une idée en passant, serait-il possible de collecter les vilaines IP pour établir une blacklist façon anti-spam ?

les mêmes IP sources reviennent en effet souvent ou proviennent d'un même sous réseau.
la blacklist permettrait de bloquer les indélicats directement au niveau du pare-feu du site.

Kriss
24/05/2013, 12h13
Je crois qu'une telle liste avait déjà été faite, je ne sais plus par qui.
Elle était tenue à jour grâce à un honeypot.

jean
24/05/2013, 14h14
tu as ca là: http://www.infiltrated.net/voipabuse/

mais je suis pas convaincu... il te faut de toute façon une bonne protection. si je devais mettre un filtrage proactif sur les ip, je ferais plutot une white list

kuusou
31/05/2013, 13h57
Merci pour ta réponse Jean.

En ce qui me concerne, je ne peux reellement pas faire une white list, car la principal utilisateur voyage, et a donc des IP dynamiques. Je vais tester l'option security !

fastm3
31/05/2013, 15h05
port knocking alors.
Liste blanche et quand vraiment necessaire "port knocking" a base juste d'iptables. C'est en plus. D'autres mesures de securité basique sont necessaires et c'est surtout pour ssh dans mon cas mais j'ouvre tout ( enfin juste le firewall ) si l'ip est reconnue comme fiable. Moi je le fais au telnet/kitty le knock knock si necessaire mais il faut peut etre un outil pour un client lambda, ca existe mais jamais trop regardé.
Fastm3.

jean
31/05/2013, 15h47
perso, j'ai mis dans iptables les user agent et "signatures" de tous les scanners existants avec une regle DROP

je suis scanné 10 à 20 fois par jour (22 hier...) et c'est exceptionnel que quelqu'un passe - et derrière il y a F2B qui attend au coin du bois

l'intérêt de telles règles est que le scanner ne voit pas qu'il y a un serveur voip, car dès le premier paquet, je jette ! en 4 ans, pas plus d'une dizaine de fois quelqu'un a passé cette première barrière.

je peux filer les regles en mp si ca interesse, mais je les mets pas publiques, je n'ai pas envie que des rigolos finissent par s'adapter et qu'on se fasse emm.der !!!


J.

kuusou
04/06/2013, 19h43
perso, j'ai mis dans iptables les user agent et "signatures" de tous les scanners existants avec une regle DROP

je suis scanné 10 à 20 fois par jour (22 hier...) et c'est exceptionnel que quelqu'un passe - et derrière il y a F2B qui attend au coin du bois

l'intérêt de telles règles est que le scanner ne voit pas qu'il y a un serveur voip, car dès le premier paquet, je jette ! en 4 ans, pas plus d'une dizaine de fois quelqu'un a passé cette première barrière.

je peux filer les regles en mp si ca interesse, mais je les mets pas publiques, je n'ai pas envie que des rigolos finissent par s'adapter et qu'on se fasse emm.der !!!


J.

si je ne dis pas de bétises les iptables ne survivent pas naturellement au reboot non ? donc ta règle d'iptables est chargée en cron ?

jean
04/06/2013, 23h07
oui, les regles iptables ne survivent pas, mais généralement, tu as le fichier /etc/sysconfig/iptables sous centos, ou debian, tu crée ton fichier librement et tu ajoute un fichier init (pas cron)

accessoirement, mon serveur est rebooté genre tous les 12-18 mois, et encore !