HOWTO: Thwarting SIP Scanners during Set-up
absteeve:
Yeah, that! How?
Shale:
absteeve wrote:
>1) I don't understand WHY it works or WHAT it does, so I'm not all
>that confident that I didn't just block everyone from calling me.
The SIP provider puts your account number in its packet. The malefactor won't know that number to put it in.
>
>2) I don't understand why my PROVIDER isn't solving this issue. I
>use Callcentric, which seems to me to be a large, reputable, and
>experienced provider. Why are they using default ports and
>allowing such attacks to their customers?
Your provider is totally not involved. The request came directly to you without involving your provider.
>
>3) I'm also trying to figure out if the reason for these attacks
>suddenly hitting me is because a) I switched from voip.ms to
>Callcentric or b) I switched from a PAP2T to a OBi100 or c) I
>switched from being behind a router to being in front of it.
Yes, probably 1c.. However not all routers would have saved you. If your router opens the port, you will still get that 4am wakeup. Most of us that got bit were behind routers.
Another possibility is that the SIP scanner had not found you yet.
sdb-:
Quote from: Shale on January 08, 2014, 12:46:34 pm
>c) I switched from being behind a router to being in front of it.
Yes, probably 1c.. However not all routers would have saved you. If your router opens the port, you will still get that 4am wakeup. Most of us that got bit were behind routers.
Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).
Every IP packet has a source address and source port, and a destination address and destination port. The firewall in "allow outgoing" establishes an expected session from the source address and port to the destination address and port and will allow a response which has both tuples in the opposite locations.
In other words, if my OBi at 172.31.0.8:22334 tries to talk thru my firewall to 1.2.3.4:5260 on the outside, only responses from 1.2.3.4 will be allowed in, and only if they come from port 5260 and are directed inward to port 22334.
If a port is forwarded, then it will be "open." Otherwise if you have a router which just decides to "open" the port to any incoming traffic, it is broken.
Shale:
Quote from: sdb- on January 09, 2014, 06:55:07 am
Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).
1. http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation shows the various methods of translation. People have to deal with what is their router does do rather than what it "should" do.
2. Some people put the OBi into the DMZ to get things working, and don't keep working beyond that. Some just pass through some ports, but that still leaves them open to SIP scanners.
3. New firmware, such as Tomato, can change the method of port translation for many routers.
4. The Oleg method saves you even if your router is in the DMZ.
5. OBi now incorporates the Oleg method when it does the setup for its list of SIP providers.
sdb-:
Quote from: Shale on January 09, 2014, 07:30:45 am
Quote from: sdb- on January 09, 2014, 06:55:07 am
Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).
1. http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation shows the various methods of translation. People have to deal with what is their router does do rather than what it "should" do.
Yeah, but have you have proved to have one? In that description, "full cone NAT" is the only one which does the behavior you described.
Further, that terminology of describing port translation is obsolete because it did not adequately describe what happens in the real world.
Quote from: wikipedia
This terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior. Many NAT implementations combine these types, and it is therefore better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology.
and
Quote from: ibid
Especially, most NAT translators combine symmetric NAT for outgoing connections with static port mapping, where incoming packets to the external address and port are redirected to a specific internal address and port.
Which is the normal behavior today and that static port mapping (either individually or via a "DMZ host") is only way I have ever seen intentional "full cone NAT" existing in the real world.
As for your #2, of course users can break things.
Your #3, see above.
The rest, yeah I agree.
By the way, I write router firmware for a living and have been implementing and designing network protocols since long before NAT was standardized. I have not seen it all. But I have worked with a lot of it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page