sean darcy
2010-Jun-11 21:55 UTC
[asterisk-users] How to stop intruder from registering sip?
This is a small 12 line system, internal extensions 150 - 180. I didn't have a phone on 151. Here's the sip.conf stanza: ;;[151] ;;type=friend ;;context=longdistance ;;callerid="Conf Room" <151> ;;secret=0000 ;;host=dynamic ;;qualify=yes ;;dtmfmode=rfc2833 ;;allow=all ;;defaultuser=151 ;;nat=yes ;;canreinvite=no There's no DISA. And then somehow (how???) ip address 79.117.17.247 becomes extension 151 and starts making calls to West Africa. Now contactdeny and contactpermit over solve the problem. For instance, I can't register with my voip provider. I don't care about peers who I make calls to, or receive calls from. I'm just stunned someone can become a peer and make calls themselves. How do I fix this in some reasonable way. sean [Jun 10 15:51:19] VERBOSE[1662] chan_sip.c: -- Registered SIP '151' at 79.117.17.247 port 5060 [Jun 10 15:51:20] NOTICE[1662] chan_sip.c: Peer '151' is now Reachable. (161ms / 2000ms) [Jun 10 15:51:20] NOTICE[1662] chan_sip.c: Received SIP subscribe for peer without mailbox: 151 [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using SIP RTP TOS bits 184 [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using SIP RTP CoS mark 5 [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using SIP VRTP CoS mark 6 [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using UDPTL TOS bits 184 [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using UDPTL CoS mark 5 [Jun 10 15:51:22] VERBOSE[4780] pbx.c: -- Executing [01125240212154 at longdistance:1] Answer("SIP/151-000000ae", "") in new stack [Jun 10 15:51:22] VERBOSE[4780] pbx.c: -- Executing [01125240212154 at longdistance:2] Gosub("SIP/151-000000ae", "DialOut,s,1(01125240212154 ,DAHDI/g0)") in new stack ......... [Jun 10 15:51:22] VERBOSE[4780] pbx.c: -- Executing [s at DialOut:9] Dial("SIP/151-000000ae", "DAHDI/g0/01125240212154") in new stack [Jun 10 15:51:22] VERBOSE[4780] chan_dahdi.c: -- Requested transfer capability: 0x00 - SPEECH [Jun 10 15:51:22] VERBOSE[4780] app_dial.c: -- Called g0/01125240212154 [Jun 10 15:51:22] VERBOSE[4780] app_dial.c: -- DAHDI/2-1 is proceeding passing it to SIP/151-000000ae [Jun 10 15:51:23] VERBOSE[4780] app_dial.c: -- DAHDI/2-1 is making progress passing it to SIP/151-000000ae [Jun 10 15:51:23] VERBOSE[4780] app_dial.c: -- DAHDI/2-1 is making progress passing it to SIP/151-000000ae [Jun 10 15:51:25] VERBOSE[4780] app_dial.c: -- SIP/151-000000ae requested special control 16, passing it to DAHDI/2-1 [Jun 10 15:51:25] VERBOSE[4780] channel.c: -- Music class default requested but no musiconhold loaded. [Jun 10 15:51:25] VERBOSE[4780] app_dial.c: -- SIP/151-000000ae requested special control 20, passing it to DAHDI/2-1
Fred Posner
2010-Jun-11 23:38 UTC
[asterisk-users] How to stop intruder from registering sip?
On Jun 11, 2010, at 5:55 PM, sean darcy wrote:> This is a small 12 line system, internal extensions 150 - 180. I didn't > have a phone on 151. Here's the sip.conf stanza: > --snip-- > There's no DISA. And then somehow (how???) ip address 79.117.17.247 > becomes extension 151 and starts making calls to West Africa. > > Now contactdeny and contactpermit over solve the problem. For instance, > I can't register with my voip provider. I don't care about peers who I > make calls to, or receive calls from. I'm just stunned someone can > become a peer and make calls themselves. > > How do I fix this in some reasonable way. > > seanWhat is the default context in sip.conf? Does it allow outbound calls? Do you have autocreatepeer=no? Fred Posner http://qxork.com
When will you people learn ... you set the secret=0000 and it's one of the many frequent passwords most people sets out of being lazy ... that simply says ... guess my password and call through my pbx for free ... so again ... 1) bad people scan extensions 100-199 and 1000-9999 trying to guess your password if you were nice enough to set it within a known statistical easy guess 2) either use complicated passwords and sip accounts other than 100-199 1000-9999 or install the fail2ban Martin On Fri, Jun 11, 2010 at 4:55 PM, sean darcy <seandarcy2 at gmail.com> wrote:> This is a small 12 line system, internal extensions 150 - 180. I didn't > have a phone on 151. Here's the sip.conf stanza: > > ;;[151] > ;;type=friend > ;;context=longdistance > ;;callerid="Conf Room" <151> > ;;secret=0000 > ;;host=dynamic > ;;qualify=yes > ;;dtmfmode=rfc2833 > ;;allow=all > ;;defaultuser=151 > ;;nat=yes > ;;canreinvite=no > > There's no DISA. And then somehow (how???) ip address 79.117.17.247 > becomes extension 151 and starts making calls to West Africa. > > Now contactdeny and contactpermit over solve the problem. For instance, > I can't register with my voip provider. I don't care about peers who I > make calls to, or receive calls from. I'm just stunned someone can > become a peer and make calls themselves. > > How do I fix this in some reasonable way. > > sean > > [Jun 10 15:51:19] VERBOSE[1662] chan_sip.c: ? ? -- Registered SIP '151' > at 79.117.17.247 port 5060 > [Jun 10 15:51:20] NOTICE[1662] chan_sip.c: Peer '151' is now Reachable. > (161ms / 2000ms) > [Jun 10 15:51:20] NOTICE[1662] chan_sip.c: Received SIP subscribe for > peer without mailbox: 151 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: ? == Using SIP RTP TOS bits 184 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: ? == Using SIP RTP CoS mark 5 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: ? == Using SIP VRTP CoS mark 6 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: ? == Using UDPTL TOS bits 184 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: ? == Using UDPTL CoS mark 5 > [Jun 10 15:51:22] VERBOSE[4780] pbx.c: ? ? -- Executing > [01125240212154 at longdistance:1] Answer("SIP/151-000000ae", "") in new stack > [Jun 10 15:51:22] VERBOSE[4780] pbx.c: ? ? -- Executing > [01125240212154 at longdistance:2] Gosub("SIP/151-000000ae", > "DialOut,s,1(01125240212154 > ,DAHDI/g0)") in new stack > ......... > [Jun 10 15:51:22] VERBOSE[4780] pbx.c: ? ? -- Executing [s at DialOut:9] > Dial("SIP/151-000000ae", "DAHDI/g0/01125240212154") in new stack > [Jun 10 15:51:22] VERBOSE[4780] chan_dahdi.c: ? ? -- Requested transfer > capability: 0x00 - SPEECH > [Jun 10 15:51:22] VERBOSE[4780] app_dial.c: ? ? -- Called g0/01125240212154 > [Jun 10 15:51:22] VERBOSE[4780] app_dial.c: ? ? -- DAHDI/2-1 is > proceeding passing it to SIP/151-000000ae > [Jun 10 15:51:23] VERBOSE[4780] app_dial.c: ? ? -- DAHDI/2-1 is making > progress passing it to SIP/151-000000ae > [Jun 10 15:51:23] VERBOSE[4780] app_dial.c: ? ? -- DAHDI/2-1 is making > progress passing it to SIP/151-000000ae > [Jun 10 15:51:25] VERBOSE[4780] app_dial.c: ? ? -- SIP/151-000000ae > requested special control 16, passing it to DAHDI/2-1 > [Jun 10 15:51:25] VERBOSE[4780] channel.c: ? ? -- Music class default > requested but no musiconhold loaded. > [Jun 10 15:51:25] VERBOSE[4780] app_dial.c: ? ? -- SIP/151-000000ae > requested special control 20, passing it to DAHDI/2-1 > > > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > ? ? ? ? ? ? ? http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > ? http://lists.digium.com/mailman/listinfo/asterisk-users >
lol when then if he knows the IP of his provider plus a few phones he can just allow these ... and problem solved forever Martin On Fri, Jun 11, 2010 at 9:02 PM, Steve Edwards <asterisk.org at sedwards.com> wrote:> On Fri, 11 Jun 2010, Martin wrote: > >> if you know IP then ban with iptables >> >> iptables -A INPUT -s IP -j REJECT > > Ever play http://en.wikipedia.org/wiki/Whac-A-Mole ? > > -- > Thanks in advance, > ------------------------------------------------------------------------- > Steve Edwards ? ? ? sedwards at sedwards.com ? ? ?Voice: +1-760-468-3867 PST > Newline ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Fax: +1-760-731-3000 > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > ? ? ? ? ? ? ? http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > ? http://lists.digium.com/mailman/listinfo/asterisk-users >
sean darcy
2010-Jun-12 13:09 UTC
[asterisk-users] How to stop intruder from registering sip?
sean darcy wrote:> This is a small 12 line system, internal extensions 150 - 180. I didn't > have a phone on 151. Here's the sip.conf stanza: > > ;;[151] > ;;type=friend > ;;context=longdistance > ;;callerid="Conf Room" <151> > ;;secret=0000 > ;;host=dynamic > ;;qualify=yes > ;;dtmfmode=rfc2833 > ;;allow=all > ;;defaultuser=151 > ;;nat=yes > ;;canreinvite=no > > There's no DISA. And then somehow (how???) ip address 79.117.17.247 > becomes extension 151 and starts making calls to West Africa. > > Now contactdeny and contactpermit over solve the problem. For instance, > I can't register with my voip provider. I don't care about peers who I > make calls to, or receive calls from. I'm just stunned someone can > become a peer and make calls themselves. > > How do I fix this in some reasonable way. > > sean > > [Jun 10 15:51:19] VERBOSE[1662] chan_sip.c: -- Registered SIP '151' > at 79.117.17.247 port 5060 > [Jun 10 15:51:20] NOTICE[1662] chan_sip.c: Peer '151' is now Reachable. > (161ms / 2000ms) > [Jun 10 15:51:20] NOTICE[1662] chan_sip.c: Received SIP subscribe for > peer without mailbox: 151 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using SIP RTP TOS bits 184 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using SIP RTP CoS mark 5 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using SIP VRTP CoS mark 6 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using UDPTL TOS bits 184 > [Jun 10 15:51:21] VERBOSE[1662] netsock.c: == Using UDPTL CoS mark 5 > [Jun 10 15:51:22] VERBOSE[4780] pbx.c: -- Executing > [01125240212154 at longdistance:1] Answer("SIP/151-000000ae", "") in new stack > [Jun 10 15:51:22] VERBOSE[4780] pbx.c: -- Executing > [01125240212154 at longdistance:2] Gosub("SIP/151-000000ae", > "DialOut,s,1(01125240212154 > ,DAHDI/g0)") in new stack > ......... > [Jun 10 15:51:22] VERBOSE[4780] pbx.c: -- Executing [s at DialOut:9] > Dial("SIP/151-000000ae", "DAHDI/g0/01125240212154") in new stack > [Jun 10 15:51:22] VERBOSE[4780] chan_dahdi.c: -- Requested transfer > capability: 0x00 - SPEECH > [Jun 10 15:51:22] VERBOSE[4780] app_dial.c: -- Called g0/01125240212154 > [Jun 10 15:51:22] VERBOSE[4780] app_dial.c: -- DAHDI/2-1 is > proceeding passing it to SIP/151-000000ae > [Jun 10 15:51:23] VERBOSE[4780] app_dial.c: -- DAHDI/2-1 is making > progress passing it to SIP/151-000000ae > [Jun 10 15:51:23] VERBOSE[4780] app_dial.c: -- DAHDI/2-1 is making > progress passing it to SIP/151-000000ae > [Jun 10 15:51:25] VERBOSE[4780] app_dial.c: -- SIP/151-000000ae > requested special control 16, passing it to DAHDI/2-1 > [Jun 10 15:51:25] VERBOSE[4780] channel.c: -- Music class default > requested but no musiconhold loaded. > [Jun 10 15:51:25] VERBOSE[4780] app_dial.c: -- SIP/151-000000ae > requested special control 20, passing it to DAHDI/2-1 >I decided to include the following in each sip.conf stanza that has an outgoing context: deny=0.0.0.0/0.0.0.0 permit=10.10.10.0/24 I didn't want to mess around with secrets/passwords. And I want to allow registration for incoming contexts. Won't this do it? Is this how my intruder did this? register => 151:0000@<my.pbx.ip.address> Dial(<some.West.African.number>,SIP/151:0000@<my.pbx.ip.address>) Blacklisting won't work - see Whack-a-mole. Does the deny/permit do the trick? sean sean
Dave Platt
2010-Jun-13 17:59 UTC
[asterisk-users] How to stop intruder from registering sip?
> If you leave your asterisk box open to the world with passwords like 0000 > you deserve to be hacked..Well, without making a moral judgment, I will agree that you are *going* to be hacked if you do this! The O.P. seems to have made two (fairly common) mistakes: - Used a "secret" so obvious that it could be guessed... and even if not, so short that it could have been determined by a very simple brute-force attack. - Used the user's extension number as the SIP user ID... and thus making it easy to figure out which user IDs on which a password attack could be carried out. Doing a brute-force SIP-registration attack against all possible 3- and 4-digit extensions, using a handful of obvious "secret" strings (0000 through 9999, 1234, 4321, same number as the extension) wouldn't take an attacker very long at all. Nor would trying to call all of these numbers once to figure out which extensions exist, then doing a brute-force password attack against those which exist. I have no doubt that there are numerous crackers out on the net doing just these sorts of attacks on a regular basis. The cure for these problems is, obviously, "don't do that": (1) SIP user IDs should not be based on the extension number, and preferably should not be based on the owner's name or user login. Make 'em hard to guess or brute-force! (2) Make the secrets equally hard to guess or brute-force. No short strings of numbers, no dictionary words or simple leet-speak transforms of them, etc. One of your best tools is a program or script to generate random sequences of letters and digits and other legal- in-SIP-names characters. Try something like dd if=/dev/urandom bs=512 count=1 | base64 and then copy some 10- or 12-character substrings out of this mass of gibberish and use 'em for SIP secrets. With this many bits of randomness in the secrets, they'll be effectively invulnerable to guessing or brute force attacks.> Are your travelling people using softphones? If they are VPN would be a good > idea..A very good idea, and not just for security reasons. Running SIP over a VPN tunnel can be a very effective remedy for all sorts of firewall- and NAT-related problems. I've found that running OpenVPN between my various SIP clients, and my Asterisk server, produces far better results than depending on STUN or on SIP-aware routers and firewalls.
Dave Platt
2010-Jun-14 16:22 UTC
[asterisk-users] How to stop intruder from registering sip?
> As I mentioned, I'm not inclined to mess with the secrets, too much > hassle for users.I'm afraid that I have to consider that attitude to be a bit like saying "It's too much hassle for us to insist that our employees lock their desk drawers and the front door... or wash their hands after going to the bathroom... or cover their mouths when they sneeze. Oh, yeah, we keep the combination to the corporate safe on a yellow sticky-note on the bulletin board, so that anyone who forgets it can figure it out quickly." There are ways to make stronger secrets easier to work with. One method creates secret phrases by concatenating a bunch of randomly-chosen dictionary words. If you have enough such words in the dictionary you can create phrases which have enough randomness to survive brute-force attacks but which aren't too difficult to type in correctly. For example, such a gibberish-generator might output fizzy.basal.nerfy.dogma.colma.flinx It's your choice... but these basic security principles about setting secrets/passwords have the fruits of many peoples' expen$ive experience at the high cost of *not* doing things properly. If the cost of doing things securely is that you have to spend a few minutes of IT-guru time setting up each user's phone or softphone, or need to write a document-generator which prints out step-by-step instructions for each user with the necessary user-name and secret included... it could be a *very* good investment.> That's why I'm considering deny/permit.> Does that solve my problem?*Only* if you have complete physical control over *every* network on which those phones will be used, *and* all of your employees are completely trustworthy. It's really no solution at all if you need to have "road warriors" using soft-phones on networks across the world, since you won't be able to deny IP addresses meaningfully in that case. All it would take would be one such employee using a softphone via an insecure network (e.g. open WiFi access point), somebody sniffs the protocol and sees the registration and records the extension number and then does a brute-force secret-guessing attack. Boom. You're out hundreds or thousands of dollars of calling costs before you can react. Scammers can use your SIP system to make calls to "premium" phone numbers that cost several dollars per minute... and the scammer may well get a portion of this revenue. Big companies have ended up losing tens of thousands of dollars to this sort of attack against their PBX systems. Or, worse... your SIP secrets end up in the hands of a cybergang which starts using your system for criminal activities (e.g. drug-trafficing, making scam calls to homeowners, etc.), and you find your company facing investigation by law enforcement, or your SIP provider cuts you off due to abuse complaints. The secondary cost of either of these to your business could be severe. As Dirty Harry said, "How lucky do you feel?". You've already been hit once.> But I'm struck with your notion of having sip user ids different from > extensions. That would not require any user effort, or messing with each > phone. But... > > We use a combo of aastra 9133i and 57i's. Don't the user id and the > extension HAVE to be the same? I had thought the aastra's used the > extension as the SIP id to register.By no means - at least, not in the 9133i, and I'd be surprised if the 57i had that requirement. Look in the Administration manual for the 9133i, Appendix A, "SIP Basic, Global Settings", "SIP Global Authentication". This is where you can set the "authentication name" and "sip password", which are what the phone uses to register with the server (e.g. the SIP user name and secret). Make this name *different* from the extension name, and provide a good secret. You can also set the "SIP display name", which is what shows up on the screen, and is sent as the "From" field in the SIP protocol. You can set this to the user's primary extension number. A bit further down, there are per-line registration fields which do the same thing for individual line-presence buttons... screen name (also used for From:), user name (for SIP registration), password (SIP registration secret).
Dave Platt
2010-Jul-01 18:06 UTC
[asterisk-users] How to stop intruder from registering sip?
> That would only be true if you used random characters in your 17-character > passphrase. In fact, English text has somewhere between 0.6 and 1.5 bits of > randomness per letter, whereas an SHA1sum has no more than 4 bits of > randomness per letter. Let's assume the higher number of randomness for > your English text, which gives us 1.5 * 17, which is 25.5 bits of randomness. > Note that the prefix 3 characters have ZERO randomness per character, as they > are deterministic from the extension. That gives an even less 21 bits of > randomness. SHA1 cryptographic sums have no more than 160 bits of randomness. > > I say "no more than", because, given knowledge of the algorithm used to > determine passwords, the sum is reduced to the number of bits of randomness in > the source material. You cannot generate randomness by applying a > deterministic algorithm. However, given that the source material for the hash > sum is of a smaller bit strength than the comparative strength of the hash > algorithm, your difficulty of guessing the password is not reduced any by > using the hash algorithm for generative purposes.Agreed, on all points. Any deterministic method of this sort (e.g. hashing together the extension name with a constant-per-site salt) is vulnerable to a brute-force guessing attack against the salt. If the person who set it up used a ordinary, easily-remembered phrase as the salt, then the security of *all* of the secrets is tied to the guessability of this phrase. Brute-force dictionary attacks against plain-language words and phrases have been quite successful in the past... I've heard it said that on any multi-user system having more than a handful of users, the odds of one of those users having a guessable password are often 50% or better. I'm not in favor of using this sort of deterministic scheme (e.g. HASH(salt + public info)) for determining per-station secrets, no matter which hash algorithm is used. Instead, I recommend the scheme I originally proposed - use a random- number generator (or a cryptographically-string pseudorandom generator, fed with some entropy from an external unpredictable source) to generate individual secrets. I make three arguments: - The resulting secrets (i.e. strings of hexadecimal digits) are equally hard, or equally easy, for the end-users to deal with (assuming that we're talking about equal numbers of digits). Neither scheme has an advantage here. - Once set up, both systems are equally easy to use and administer... press a button and generate a secret. - The random- or pseudo-random method produces secrets which don't depend at all on the extension numbers (or user names, or other public information), are independent from one another, and are essentially immune to dictionary and other guessing attacks. The only way to break them is via a full brute-force search... and successfully finding one extension's secret by brute-force search doesn't help you at all in finding any other extension's. Assuming a good random-number generator, the amount of entropy (randomness) in the secrets is essentially equal to (2 ^ number-of-bits). None of these things is true of a deterministic-hashing scheme... if the salt can be guessed or determined, *every* extension's secret has been broken, and you have to immediately change *every* configuration in order to secure your system. Salts based on dictionary words and phrases have far less randomness in them than their length would imply, and that means that the resulting secrets are less random... generating longer "secret" strings doesn't fix this, and can simply give a false sense of security. -