jkroon

So recently I started bumping into an issue where I would see a buildup of traffic in the RX queue of asterisk’s SIP port 5060 (udp bound). After some scavenging of the code I quickly came to realize that asterisk only processes a single incoming SIP request (or response) at a time. So I cooked a rather crude patch (that I for the shame of it won’t share here) in an attempt to figure out what went wrong.
(more…)

So two separate clients of mine got nailed separately during the week. In both cases the root cause was a combination of weak passwords on SIP accounts, and public Internet connectivity.

For VoIP service providers obviously public Internet connectivity is not negotiable. Often clients are able to set their own passwords. Usually you get bent over the table pretty quickly – fortunately in the latter case one can just have a disclaimer which purely serves as an income protector – it does NOT save your business relationship with your client. In the case of PABX systems usually they are behind a firewall that only allows connectivity from the local network, but we had one case now where the router “accidentally” (misconfiguration due to misunderstanding of how the router’s DMZ and port-forwarding functionality works – not configured by ULS) forwarded SIP traffic to the VoIP server (router was set up to forward all traffic instead of just TCP/22 for ssh).

So in the case of a publicly accessible VoIP service – what can be done to protect both your client and yourself?
(more…)

So I’ve got a client that has a need to have his clients dial into his network using ISDN. Right, so stagger a bunch of ISDN modems, use mgetty on them … yea yea. Figured I’d go the interesting route, get a few quad-port Digium ISDN PRI cards into a box (5 cards, => 5 * 4 * 40 = 20 * 30 = 600 odd available channels) and do this using asterisk.
(more…)