PDA

Voir la version complète : Renseignement boitier Cisco SPA 3102 contre le piratage téléphonique.



xunil2003
14/01/2014, 14h28
Bonjour,

Mon fai est Free, pour des raisons économiques je voudrais utiliser le boitier Cisco SPA 3102 (http://www.ldlc.com/fiche/PB00068083.html), pour effectuer des appels de mobile, car depuis un compte sip de free, il est impossible d’appeler un mobile.
Donc avec le boîtier qui serait connecté directement sur ma ligne RTC derrière la freebox, me donnera accès aux numéros de mobile via mes postes sip.
Ce boîtier me permettra également de branché dessus mes téléphones RTC pour avoir accès à asterisk et aux comptes SIP.
Mais j'ai une question, es-ce que le fait de posséder un boîtier Sisco 3102 restes piratables téléphoniquement depuis le net, car même si les communications depuis la ligne RTC (derrière la freebox) des n° de mobiles et gratuite, les n° en 08 ... ne le son pas ainsi que certains n° internationaux ?
Dans ce cas-là quelle solution est elle envisageable ?

Merci.

therebel23
14/01/2014, 22h29
Bonjour,

ça dépend ce que tu veux faire avec ton boitier SPA. Si tu le met en IP privée et que tu ne le NATe pas, il y'a peu de risques que tu te fasses pirater.

Ou se trouverait ton serveur asterisk dans ta configuration ?

xunil2003
28/01/2014, 14h43
Bonjour,

Merci de votre réponse.

Asterisk ce trouve sur mon serveur a mon domicile.
Mon serveur me sert également d’hébergeur de site web domestique pour la domotique et asterisk, il est ouvert pour l’extérieur afin d’accédé à mon site web et à asterisk depuis mon ip exterieur.

Voilà ou se trouve mon serveur Asterisk dans ma config.

serveur@debian:~$ whereis asterisk
asterisk: /usr/sbin/asterisk /etc/asterisk /lib/asterisk /usr/lib/asterisk /usr/include/asterisk.h /usr/include/asterisk /usr/share/asterisk /usr/share/man/man8/asterisk.8
serveur@debian:~$

Et voici la configuration du parefeux de mon iptables :

serveur@debian:~$ sudo iptables -L
sudo: unable to resolve host debian
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP icmp -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp-data
ACCEPT tcp -- anywhere anywhere tcp dpt:www
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:xmpp-client
ACCEPT tcp -- anywhere anywhere tcp dpt:microsoft-ds
ACCEPT tcp -- anywhere anywhere tcp dpt:netbios-ssn
ACCEPT udp -- anywhere anywhere udp dpts:netbios-ns:netbios-dgm
ACCEPT udp -- anywhere anywhere udp dpt:sip
ACCEPT udp -- anywhere anywhere udp dpts:10000:20000
ACCEPT tcp -- anywhere anywhere tcp dpt:4661
ACCEPT udp -- anywhere anywhere udp dpt:4664
ACCEPT udp -- anywhere anywhere udp dpt:4674
LOG all -- anywhere anywhere LOG level warning prefix `[INPUT DROP]:'

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
serveur@debian:~$


Merci.

nens
28/01/2014, 22h05
Hello

je peux peux être me tromper mais cette ligne la me dérange
ACCEPT all -- anywhere anywhere
on dirait que tu accepte tout depuis tout vers tout


A titre de comparaison mes règles INPUT ressemblent à ça!!!

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
354K 71M BADTCP all -- * * 0.0.0.0/0 0.0.0.0/0
354K 71M CUSTOMINPUT all -- * * 0.0.0.0/0 0.0.0.0/0
51 29049 ACCEPT udp -- * * IPdemonfounisseurSIP1 0.0.0.0/0 udp dpt:5060
49 23059 ACCEPT udp -- * * IPdemonfounisseurSIP2 0.0.0.0/0 udp dpt:5060
0 0 DROP udp -- * * IPFREEPHONIE 0.0.0.0/0 udp dpt:5060 STRING match "Cirpack KeepAlive Packet SIP" ALGO name bm TO 65535
354K 71M GUARDIAN all -- * * 0.0.0.0/0 0.0.0.0/0
354K 71M IPTVINPUT all -- * * 0.0.0.0/0 0.0.0.0/0
354K 71M GUIINPUT all -- * * 0.0.0.0/0 0.0.0.0/0
348K 70M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
5870 950K IPSECINPUT all -- * * 0.0.0.0/0 0.0.0.0/0
5836 940K OVPNINPUT all -- * * 0.0.0.0/0 0.0.0.0/0
4079 410K OPENSSLVIRTUAL all -- * * 0.0.0.0/0 0.0.0.0/0 /* OPENSSLVIRTUAL INPUT */
4079 410K TOR_INPUT all -- * * 0.0.0.0/0 0.0.0.0/0
332 19451 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP all -- * * 127.0.0.0/8 0.0.0.0/0 state NEW
0 0 DROP all -- * * 0.0.0.0/0 127.0.0.0/8 state NEW
3265 304K ACCEPT !icmp -- green0 * 0.0.0.0/0 0.0.0.0/0 state NEW
482 87001 DHCPBLUEINPUT all -- * * 0.0.0.0/0 0.0.0.0/0
482 87001 OPENSSLPHYSICAL all -- * * 0.0.0.0/0 0.0.0.0/0
482 87001 WIRELESSINPUT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
482 87001 REDINPUT all -- * * 0.0.0.0/0 0.0.0.0/0
482 87001 XTACCESS all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
388 74178 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix "DROP_INPUT "
480 86901 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 /* DROP_INPUT */



Si tu fais un iptables -v -L t'as la même chose ?

xunil2003
31/01/2014, 13h55
Bonjour,

A priori ça n'y est plus.


serveur@debian:~$ sudo iptables -v -L
sudo: unable to resolve host debian
[sudo] password for serveur:
Chain INPUT (policy DROP 130K packets, 11M bytes)
pkts bytes target prot opt in out source destination
5184K 522M ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
42 2520 ACCEPT all -- lo any anywhere anywhere
0 0 DROP icmp -- any any anywhere anywhere
8931 525K ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ftp
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ftp-data
2440 141K ACCEPT tcp -- any any anywhere anywhere tcp dpt:www
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ipp
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:xmpp-client
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:microsoft-ds
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:netbios-ssn
43256 4177K ACCEPT udp -- any any anywhere anywhere udp dpts:netbios-ns:netbios-dgm
3447 2095K ACCEPT udp -- any any anywhere anywhere udp dpt:sip
0 0 ACCEPT udp -- any any anywhere anywhere udp dpts:10000:20000
4615 245K ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:4661
0 0 ACCEPT udp -- eth0 any anywhere anywhere udp dpt:4664
0 0 ACCEPT udp -- eth0 any anywhere anywhere udp dpt:4674
130K 11M LOG all -- any any anywhere anywhere LOG level warning prefix `[INPUT DROP]:'

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 97131 packets, 7104K bytes)
pkts bytes target prot opt in out source destination
4118K 7829M ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
42 2520 ACCEPT all -- any lo anywhere anywhere
serveur@debian:~$

Merci.

nens
31/01/2014, 22h02
Si c'est bon ta ligne existe toujours mais avec l'option -v
on remarque que l'interface c'est lo donc loopback .
C'est normal
c'est l'interface lo 127.0.0.1 qui utilise cette régle ...

tempest69
01/02/2014, 10h25
Bonjour,
Utilisant maintenant pfsense, je ne suis plus sur de mes restes sur iptables, je me permet de donner quand même un avis sur ce que je viens de lire.
La ligne suivante me parait dangereuse (mais impossible à dire sans connaître le contexte global)
ACCEPT udp -- anywhere anywhere udp dpt:sip
Elle ouvre le port udp:sip à l'extérieur, il risque d'y avoir des robots qui sonnent à la porte d'asterisk...

Mais je présume que eth0 n'est pas relié directement au WAN et qu'il y a un dispositif entre (firewall, box).
Si ce dispositif est paramétré pour rediriger le port udp:SIP du Wan systématiquement sur le serveur (ou pire si le serveur est en DMZ), là il y a un soucis de sécurité.
il faudrait éventuellement réduire en mettant source et/ou destination avec l'adresse ip du serveur sip de free pour filtrer le port udp:sip.
Sauf bien-sur si c'est normal que asterisk soit ouvert sur l'extérieur (dans ce cas bien blinder la partie authentification d'asterisk.... )
Sachant que le "sip" de Free n'est pas un vrai sip (on ne peut pas appeller un abonné free directement par sip, mais un abonné Free peut appeler en utilisant ce protocole - et encore pas sur que l'on puisse appeler des adresses sip). Le fait de réduire le transit sip du wan en entrant/sortant sur l'adresse ip du serveur sip de free devrait régler le soucis sans en créer d'autre.
Bref, déjà essayer de vérifier si possible de se connecter avec un softphone (sur asterisk et pas free sip biensur) et téléphoner depuis chez un ami par exemple...