Thread Info
  • State Not Answered
  • Replies 13 replies
  • Subscribers 0 subscribers
  • Views 1628 views
  • Users 0 members are here
Options
Suggested

[7.880][BUG][OPEN] Maybe ATA responding to traffic outside of range

RFCat_vk_01
Hi,
last night I ran a security scan of my ASG.
Turned up some interesting results, but I don't get see some of them unless I pay money.

The one that does interest me and causes me some concern is SIP report.

I have SIP security enabled and sites that the ATAs can talk to as part of the setup.
The security scan site is not in the IP range allowed into or out of the ASG for VoIP traffic, so why was the security scan able to talk to and get one of my ATAs to respond to it. I know this limiting access used to work under previous versions.

Ian M
Parents
  • 0
    Can't tell you anything about that, simply because we do not know what and how they scan. There's even the possibility that their scanner is faulty.

    What you can do is, try the following command on the ASG (as root): [FONT="Courier New"] iptables -L AUTO_FORWARD -n -v [/FONT]

    This should list something similar to the thing below:

    [FONT="Courier New"][SIZE="2"]Chain AUTO_FORWARD (1 references)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 CONFIRMED  tcp  --  *      *       10.128.128.0/23      10.128.128.0/23     tcp spts:1:65535 dpt:5060 
        0     0 CONFIRMED  udp  --  *      *       10.128.128.0/23      10.128.128.0/23     udp spts:1:65535 dpt:5060 
    [/SIZE][/FONT]



    Verify that source and destination match what you've configured, and maybe go for some length and even try manually with nmap or some other scanner (that you personally trust) from different allowed and not-allowed addressed.

    The main problem i see is that these days it is really "hip" to implement VoIP functionality in Home-Router products, so if i were driving some "security scanner business", i'd grab the low hanging fruit and frighten everyone, even if there are some "false positives". You know what i mean?

    I think my point is: don't trust anybody who says "Watch out, you're in Danger!" but doesn't tell you which danger unless you pay him. Test it yourself.

    [SIZE="2"]PS: i took a look at it, but can't reproduce it here[/SIZE]
Reply
  • 0
    Can't tell you anything about that, simply because we do not know what and how they scan. There's even the possibility that their scanner is faulty.

    What you can do is, try the following command on the ASG (as root): [FONT="Courier New"] iptables -L AUTO_FORWARD -n -v [/FONT]

    This should list something similar to the thing below:

    [FONT="Courier New"][SIZE="2"]Chain AUTO_FORWARD (1 references)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 CONFIRMED  tcp  --  *      *       10.128.128.0/23      10.128.128.0/23     tcp spts:1:65535 dpt:5060 
        0     0 CONFIRMED  udp  --  *      *       10.128.128.0/23      10.128.128.0/23     udp spts:1:65535 dpt:5060 
    [/SIZE][/FONT]



    Verify that source and destination match what you've configured, and maybe go for some length and even try manually with nmap or some other scanner (that you personally trust) from different allowed and not-allowed addressed.

    The main problem i see is that these days it is really "hip" to implement VoIP functionality in Home-Router products, so if i were driving some "security scanner business", i'd grab the low hanging fruit and frighten everyone, even if there are some "false positives". You know what i mean?

    I think my point is: don't trust anybody who says "Watch out, you're in Danger!" but doesn't tell you which danger unless you pay him. Test it yourself.

    [SIZE="2"]PS: i took a look at it, but can't reproduce it here[/SIZE]
Children
  • 0 in reply to kbr
    Hi kbr,
    this test result was rated as of no concern by the security scanner.

    It interested me for 2 reasons
    1/. I had deliberately reduced the destination range on my ATAs because I found they were registering with places I didn't have accounts with world wide.

    2/. because this result wasn't in my previous scan.

    Ian M
Cookie Information Banner