Re: [asterisk-users] Securing Asterisk

[Bruce B]

Hmmm, if alwaysauthreject is already breaking RFC rules then why not break
another rule for the greater good? It would only add another layer of
security.

Maybe: *alwaysregreject=yes*
*
*
*To drop SIP packets for both unauthorized registers and anonymous calls.
Keep it off by default and then allow users to turn it on if they want to.

To be fair to OP, using Asterisk with open ports to the world is a legit use
of Asterisk even if most of us don't employ it that way or use it solely
with closed networks (VPN, etc...). There are many people who would benefit
from a security feature that would simply ignore unauthorized registers and
anonymous calls.

OP is suggesting an improvement to Asterisk; maybe people should weigh
options and see if it's time to act more on the security side or not. There
is no question that if a hacker knows there is a SIP server then they will
keep the IP on the list for later use or share it with colleagues even if it
seems secure right now. A DDoS is always a possibility and that you can't
save yourself from at all.

Right now the situation is more like this:

*Knock Knock:*
*Owner: *Whose there?
*Thief:* This is Mr. X from China, and I am here to steal your TV.
*Owner: *Hi, I am James Smith, 45, 190lbs and I have a nice laptop as well
but I am home now and I can't let you in.
*Thief (laughing):* No problem, I will come back at midnight when you are
sleeping :-)

- Bruce



On Wed, Jul 27, 2011 at 2:20 PM, Matthew J. Roth mr...@imminc.com wrote:

 Kevin P. Fleming wrote:
 
  'alwaysauthreject' in not imcompliant with any RFCs; the RFCs define
  response codes that *can* be used to indicate (for example) that the
  Request URI does not represent a target known to the receiver (404 Not
  Found), but does not mandate that the server respond with that code in
  that situation.


 Kevin,

 Thanks for the correction and I apologize if I'm propagating a
 misconception.  Am I misunderstanding this Asterisk Security Advisory?

 http://lists.digium.com/pipermail/asterisk-announce/2009-April/000177.html

   In 2006, the Asterisk maintainers made it more difficult
   to scan for valid SIP usernames by implementing an
   option called alwaysauthreject...

   ...What we have done is to carefully emulate exactly the
   same responses throughout possible dialogs, which should
   prevent attackers from gleaning this information. All
   invalid users, if this option is turned on, will receive
   the same response throughout the dialog, as if a
   username was valid, but the password was incorrect.

   It is important to note several things. First, this
   vulnerability is derived directly from the SIP
   specification, and it is a technical violation of RFC
   3261 (and subsequent RFCs, as of this date), for us to
   return these responses...

 I am asking out of genuine curiosity, because I trust your assessment
 more than my interpretation of the advisory.

 Thank you,

 Matthew Roth
 InterMedia Marketing Solutions
 Software Engineer and Systems Developer

 --
 _
 -- 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

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[john millican]

On 7/28/2011 11:31 AM, Bruce B wrote:

Hmmm, if alwaysauthreject is already breaking RFC rules then why not
break another rule for the greater good? It would only add another layer
of security.

Maybe: *alwaysregreject=yes*
*
*
*To drop SIP packets for both unauthorized registers and anonymous
calls. Keep it off by default and then allow users to turn it on if they
want to.

To be fair to OP, using Asterisk with open ports to the world is a legit
use of Asterisk even if most of us don't employ it that way or use it
solely with closed networks (VPN, etc...). There are many people who
would benefit from a security feature that would simply ignore
unauthorized registers and anonymous calls.

OP is suggesting an improvement to Asterisk; maybe people should weigh
options and see if it's time to act more on the security side or not.
There is no question that if a hacker knows there is a SIP server then
they will keep the IP on the list for later use or share it
with colleagues even if it seems secure right now. A DDoS is always a
possibility and that you can't save yourself from at all.

Right now the situation is more like this:

*Knock Knock:*
*Owner: *Whose there?
*Thief:* This is Mr. X from China, and I am here to steal your TV.
*Owner: *Hi, I am James Smith, 45, 190lbs and I have a nice laptop as
well but I am home now and I can't let you in.
*Thief (laughing):* No problem, I will come back at midnight when you
are sleeping :-)

- Bruce




What I didn't tell you Mr thief is I sleep very lightly, Have a shotgun, 
a shovel and 20 acres of back yard and I know how to use all three!


Why is there such an aversion to using the right tool for the job? 
Asterisk is not the security tool it is the voice tool!


JohnM


--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Paul Hayes]

On 23/07/11 18:38, CDR wrote:

I beg to differ. Digium is hiding from the real world and somebody is
going take the software and run with it. My customers lost in excess
of $50.000 and cut my pay in half, because of hackers. The hackers
figured out how to scan every asterisk for weak passwords or open
ports, and bang them real good. We need two things: a) disable in
sip.conf the reply for INVITES that have wrong user information, and
also, b) disable any response to any REGISTER packet altogether. Can
somebody please write  patch? Or should we go broke trying to stop the
flood of criminals coming from abroad?
Federico



Not looking for an argument here but you are asking for a solution to a 
problem that doesn't exist.  If you'd done your job properly in the 
first place you'd have put some basic intrusion detection on such as 
fail2ban, OSSEC or just a basic bash script of your own writing.  The 
solution is already there and it's not trying to bodge Asterisk into a 
firewall application.  If you'd done that (and instructions on how to 
are literally all over the Internet and this mailing list) then your 
customer wouldn't be $50,000 down, you'd still have your full pay and 
you'd not be asking for people to break Asterisk's SIP implementation 
(even more :P ) in order to stop you having to do things the right way.


Sorry if the truth hurts...

--
_
-- 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

[asterisk-users] Securing Asterisk

[CDR]

This is turning into a political issue such as the one in Washington
and the impending default on US debt. The point is that a minor change
in the code would have a dramatic effect on security, and carry a
lower impact on CPU that using Iptables. The simplicity of the change
cannot understated. The hackers do not continue sending packets with
new REGISTER attempts unless they see a response. The would move on.
Digium is being monarchical about this. It looks like a loss of
contact with reality. The vast ecosystem of Digium is made of hundreds
of people like me. I am being forced now to place Opensips in front of
Asterisk, in port 5060, set Asterisk to listen at Port 5061, and block
access to 5061 from outside. Instead of a minor change, I have to
bring a second application to the picture.
The reason why I find useless using iptables and a rule that bans an
IP address if it communicates more than a threshold of times, is
simple. I have customers that hit me 10+ times per seconds from the
same IP. It would look like a hacker, and it is not. I use a cluster
of Asterisk in the same box, a big server, and each asterisks listens
in its own network interface, and responds from it. It does work. But
iptables or fail2ban would not work in a wholesale scenario.
Any way, thanks for your attention.

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Steven Howes]

On 27 Jul 2011, at 17:11, CDR wrote:
 This is turning into a political issue such as the one in Washington
 and the impending default on US debt.

No, YOU are turning this into a political discussion.

 The point is that a minor change
 in the code would have a dramatic effect on security, and carry a
 lower impact on CPU that using Iptables. The simplicity of the change
 cannot understated. The hackers do not continue sending packets with
 new REGISTER attempts unless they see a response. The would move on.

Much as they do after you firewall them out. Have you ever tried? No? Too busy 
blaming others is suspect.

 Digium is being monarchical about this.

Why do you keep blaming Digium? Asterisk is made by a community.

 It looks like a loss of contact with reality.

Couldn't agree more.

 The vast ecosystem of Digium is made of hundreds
 of people like me. I am being forced now to place Opensips in front of
 Asterisk, in port 5060, set Asterisk to listen at Port 5061, and block
 access to 5061 from outside. Instead of a minor change, I have to
 bring a second application to the picture.

There, problem solved.

 The reason why I find useless using iptables and a rule that bans an
 IP address if it communicates more than a threshold of times, is
 simple. I have customers that hit me 10+ times per seconds from the
 same IP. It would look like a hacker, and it is not.

Which is why you don't use packet count, you look in the logs for auth failures.

 I use a cluster of Asterisk in the same box, a big server, and each asterisks 
 listens
 in its own network interface, and responds from it. It does work. But
 iptables or fail2ban would not work in a wholesale scenario.
 Any way, thanks for your attention.

Sure it would. If they're hacking one, you can block them from the lot.. I see 
no problem. Just make it look at all of the logs.

S
--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[A J Stiles]

On Wednesday 27 Jul 2011, CDR wrote:
 This is turning into a political issue such as the one in Washington
 and the impending default on US debt.

No, you are getting your knickers in a twist and blaming other people for your 
own shortcomings.

 The point is that a minor change 
 in the code would have a dramatic effect on security, and carry a
 lower impact on CPU that using Iptables.

And it would break standards.  Now, sometimes you have a good reason not to 
play by the rules  (like when you might be advertising an open service to any 
passing Tom, Dyke or Harriet).  Other times, you want everything to play by 
the rules  (like when you are trying to diagnose problems with different 
vendors' implementations of a supposedly-standardised protocol on a private 
subnet which you know accepts no inbound connections from the public 
Internet).  Guess what?  Digium can't decide, in advance and from a distance, 
which of two diametrically-opposed behaviours you are going to want.  Only 
you can decide that.

 The simplicity of the change 
 cannot understated. The hackers do not continue sending packets with
 new REGISTER attempts unless they see a response. The would move on.

And they're only seeing a response because they haven't bounced off your 
firewall.

 Digium is being monarchical about this.

As they have a right to be; it's their project.

 It looks like a loss of 
 contact with reality.

Yes.  On your part.

 The vast ecosystem of Digium is made of hundreds 
 of people like me. I am being forced now to place Opensips in front of
 Asterisk, in port 5060, set Asterisk to listen at Port 5061, and block
 access to 5061 from outside. Instead of a minor change, I have to
 bring a second application to the picture.

One tool does one job.  That's the UNIX way, it always has been and long may 
it continue to be.  You've only got to peer over the wall into the Windows 
camp to see the unintended consequences of feature creep and multiple 
re-inventions of the wheel.  Asterisk's job is to keep track of packets going 
from telephone devices to other telephone devices.  Keeping unwanted packets 
off the wires does not fall within its remit.  There are other tools for 
that.  And it actually looks as though you have found one.

Asterisk is a telephony construction kit.  Note those last two words.  Digium 
can't be held responsible for what anybody builds with it.  Whose fault do 
you think it would be, if you built a car out of Meccano, didn't fit seat 
belts, crashed it and injured yourself?

 The reason why I find useless using iptables and a rule that bans an
 IP address if it communicates more than a threshold of times, is
 simple. I have customers that hit me 10+ times per seconds from the
 same IP. It would look like a hacker, and it is not.

Then you need to whitelist their IP addresses, so fail2ban will not block 
them.  Or, use a rule that only counts failed attempts.

 I use a cluster 
 of Asterisk in the same box, a big server, and each asterisks listens
 in its own network interface, and responds from it. It does work. But
 iptables or fail2ban would not work in a wholesale scenario.

Nothing says I'm an asshole like waving your dick in people's faces.  
Especially not when they've seen bigger ones.

-- 
AJS

Answers come *after* questions.

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Matthew J. Roth]

CDR wrote:
 
 The point is that a minor change in the code would have a dramatic
 effect on security, and carry a lower impact on CPU that using
 Iptables. The simplicity of the change cannot understated.


You're in luck.  Since Asterisk is open source, you can make the
unbelievably simple change yourself.  If you make it configurable and
default it to no (so as not to break backwards compatibility, not to
mention RFC compliance), it may even get accepted into Asterisk so
that you won't have to maintain your own patchset.

This feature would actually be a bit like alwaysauthreject in that
it breaks RFC compliance for the sake of security, so it's not a
completely lost cause.  However, pining away on a mailing list about
how simple the work would be instead of doing it yourself is.

Regards,

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Kevin P. Fleming]

On 07/27/2011 01:35 PM, Matthew J. Roth wrote:


This feature would actually be a bit like alwaysauthreject in that
it breaks RFC compliance for the sake of security, so it's not a
completely lost cause.  However, pining away on a mailing list about
how simple the work would be instead of doing it yourself is.


'alwaysauthreject' in not imcompliant with any RFCs; the RFCs define 
response codes that *can* be used to indicate (for example) that the 
Request URI does not represent a target known to the receiver (404 Not 
Found), but does not mandate that the server respond with that code in 
that situation.


--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com  www.asterisk.org

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Steve Edwards]

On Wednesday 27 Jul 2011, CDR wrote nothing new, still trying to beat

life into his dead horse.

On Wed, 27 Jul 2011, A J Stiles wrote:

Whose fault do you think it would be, if you built a car out of Meccano, 
didn't fit seat belts, crashed it and injured yourself?


On the off chance the car that he actually drives has seat belts, do you 
think he chooses to implement (buckle) them?


Nothing says I'm an asshole like waving your dick in people's faces. 
Especially not when they've seen bigger ones.


Oh my, the English have such a way with words :)

While entertaining, this post has run way past it's 'sell date.'

The OP has his religious beliefs, many have tried to show him the light, 
but he just keeps digging in deeper.


--
Thanks in advance,
-
Steve Edwards   sedwa...@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

Re: [asterisk-users] Securing Asterisk

[--[ UxBoD ]--]

Simple answer to all this is to install http://lync.microsoft.com/ ... good 
luck ;)
-- 
Thanks, Phil

- Original Message -
 Kevin P. Fleming wrote:
  
  'alwaysauthreject' in not imcompliant with any RFCs; the RFCs
  define
  response codes that *can* be used to indicate (for example) that
  the
  Request URI does not represent a target known to the receiver (404
  Not
  Found), but does not mandate that the server respond with that code
  in
  that situation.
 
 
 Kevin,
 
 Thanks for the correction and I apologize if I'm propagating a
 misconception.  Am I misunderstanding this Asterisk Security
 Advisory?
 
 http://lists.digium.com/pipermail/asterisk-announce/2009-April/000177.html
 
In 2006, the Asterisk maintainers made it more difficult
to scan for valid SIP usernames by implementing an
option called alwaysauthreject...
 
...What we have done is to carefully emulate exactly the
same responses throughout possible dialogs, which should
prevent attackers from gleaning this information. All
invalid users, if this option is turned on, will receive
the same response throughout the dialog, as if a
username was valid, but the password was incorrect.
 
It is important to note several things. First, this
vulnerability is derived directly from the SIP
specification, and it is a technical violation of RFC
3261 (and subsequent RFCs, as of this date), for us to
return these responses...
 
 I am asking out of genuine curiosity, because I trust your assessment
 more than my interpretation of the advisory.
 
 Thank you,
 
 Matthew Roth
 InterMedia Marketing Solutions
 Software Engineer and Systems Developer
 
 --
 _
 -- 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
 

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Lee Howard]

Here are a few guidelines that I think may serve you well...

Firstly, every network port that is being listened-to on any 
publicly-reachable system MUST be carefully protected - typically by 
firewalling.  So, for example, you're likely going to want to block SSH 
from all but certain IPs.  In certain situations you may need to expose 
a port to the entire world.  In these cases you really have to take 
measures to limit the amount of probing that you allow from the entire 
world.  One approach that has worked for me with SIP are these with 
iptables:


iptables -N SIP_CHECK
iptables -A INPUT -p udp --dport 5060 -m state --state NEW -j SIP_CHECK
iptables -A SIP_CHECK -m recent --set --name SIP
iptables -A SIP_CHECK -m recent --update --seconds 180 --hitcount 5 
--name SIP -j DROP


This rate-limits any source to 5 new SIP communication attempts every 3 
minutes.  If you service a lot of SIP devices all running behind one IP, 
then it may simply be wise to dodge this security by accepting all SIP 
communication from that IP... if that one IP remains static, of course.  
(I can't take credit for this... I found it shared on-line by someone else.)


Secondly, disable the guest account in your sip.conf (allowguest=no).  
I recognize that this is enabled by default for the sake of convenience, 
but it's a nasty pitfall for those who are unaware of it.


Lastly, in sip.conf set alwaysauthreject = yes in order to avoid 
revealing to a brute-force attacker when they have hit on a valid username.


I'm sure there are many other good habits to follow that others here 
could share, but those come to mind with respect to the problem you've 
experienced.


Thanks,

Lee.


--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[--[ UxBoD ]--]

.
 
  --
  _
  -- 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
 
  --
  _
  -- 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
 
 
 
  --
 
  Message: 2
  Date: Sat, 23 Jul 2011 14:30:42 +
  From: Armand Fumala...@cybernet.lu
  Subject: [asterisk-users] dialplan pattern help
  To: asterisk-users@lists.digium.com
  asterisk-users@lists.digium.com
  Message-ID:
  
  2584e1abc3629c4d85a61b8dc4d27297096f1...@exchangelu.lu.cybernet.local
 
  Content-Type: text/plain; charset=us-ascii
 
  Hi all,
 
  I need help for make a pattern for a special case that i can't
  find the solution.
 
  In my case I want to match these in one pattern:
 
  This is the same ext that can come in 4 cases
 
  exten =  _42704701,1,Macro(dialfax,${EXTEN:-8}) ; case
  with 42704701
  exten =  _X42704701,1,Macro(dialfax,${EXTEN:-8});
  case with 042704701
  exten =  _42704701,1,Macro(dialfax,${EXTEN:-8}) ; case
  with +3242704701
  exten =  _XXX42704701,1,Macro(dialfax,${EXTEN:-8})  ;
  case with 3242704701
 
  I have try _.42704701 but the parser stop to check after the point
  .:-(
 
  So did you have any suggestion ?
 
  Regards
 
  Armand Fumal
 
 
 
 
  --
 
  Message: 3
  Date: Sat, 23 Jul 2011 17:48:44 +0200
  From: Patrick Listsasterisk-l...@puzzled.xs4all.nl
  Subject: Re: [asterisk-users] Securing Asterisk - How to avoid
  sending, SIP/2.0 603 Declined
  To: Asterisk Users Mailing List - Non-Commercial Discussion
  asterisk-users@lists.digium.com
  Message-ID:4e2aed5c.9080...@puzzled.xs4all.nl
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
  On 07/23/2011 04:00 PM, Paul Belanger wrote:
  A UAS rejecting an offer contained in an INVITE SHOULD return a
  488
  (Not Acceptable Here) response. Such a response SHOULD include a
  Warning header field value explaining why the offer was rejected.
  If the choice is to get hacked/DDOS'ed/etc or compliance with an
  RFC
  created by people who had no appreciation for the rather ugly
  world out
  there then why not throw the RFC out of the window and *not*
  reject an
  invite with a 488? It sounds like an interesting option to add to
  10/trunk. Better secure than compliant  sorry. Why not do a
  little
  Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with
  their
  interpretation of SIP.
 
  Regards,
  Patrick
 
 
 
  --
 
  Message: 4
  Date: Sat, 23 Jul 2011 12:07:49 -0400
  From: Paul Belangerpabelan...@digium.com
  Subject: Re: [asterisk-users] Securing Asterisk - How to avoid
  sending, SIP/2.0 603 Declined
  To: asterisk-users@lists.digium.com
  Message-ID:4e2af1d5.80...@digium.com
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
  On 11-07-23 11:48 AM, Patrick Lists wrote:
  On 07/23/2011 04:00 PM, Paul Belanger wrote:
  A UAS rejecting an offer contained in an INVITE SHOULD return a
  488
  (Not Acceptable Here) response. Such a response SHOULD include a
  Warning header field value explaining why the offer was
  rejected.
  If the choice is to get hacked/DDOS'ed/etc or compliance with an
  RFC
  created by people who had no appreciation for the rather ugly
  world out
  there then why not throw the RFC out of the window and *not*
  reject an
  invite with a 488? It sounds like an interesting option to add to
  10/trunk. Better secure than compliant  sorry. Why not do a
  little
  Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with
  their
  interpretation of SIP.
 
  Personally, I don't see this as a solutions.  SIP already provides
  some
  ability to help with security (EG: TLS, SRTP) however that is
  basically
  the extent of it.
 
  The way I see it, it is outside the scope of SIP; it's a signaling
  protocol. If 'security' is really something you want to establish,
  many
  existing tools are available to handle this (EG: VPN, firewalls,
  encryption, etc).
 
  As previously mentioned, there is no easy, simple solution.
  Securing
  ones services takes work (and time) to do it right.  Most people
  don't
  want to spend the effort monitoring it.
 
  --
  Paul Belanger
  Digium, Inc. | Software Developer
  twitter: pabelanger | IRC: pabelanger (Freenode)
  Check us out at: http://digium.com;  http

[asterisk-users] Securing Asterisk

[CDR]

Only way to cope with hackers would be that Digium comes to its senses
and accepts to disable any response to a REGISTER whose username is
unknown.  I cannot think of a good reason why Digium finds this
proposal unacceptable, given the onslaught of hacking that we are
seeing in the industry. It may take a single line of code and it would
save millions of $$$. Not only because the hackers will never get in,
but because we would save a huge CPU impact responding to hundreds of
REGISTER attempts per minute. It is a NO brainer. Can please the
Powers that Be reconsider and add this option to sip.conf?
Please?

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Alex Balashov]

On 07/26/2011 02:09 PM, CDR wrote:


Only way to cope with hackers would be that Digium comes to its
senses and accepts to disable any response to a REGISTER whose
username is unknown.  I cannot think of a good reason why Digium
finds this proposal unacceptable, given the onslaught of hacking
that we are seeing in the industry. It may take a single line of
code and it would save millions of $$$. Not only because the
hackers will never get in, but because we would save a huge CPU
impact responding to hundreds of REGISTER attempts per minute. It
is a NO brainer. Can please the Powers that Be reconsider and add
this option to sip.conf? Please?


No, because that's absolutely ridiculous.  The proper, RFC-compliant 
behaviour is to return an authentication failure in response to 
invalid credentials.  This mechanism is relied upon for legitimate 
functionality, such as letting the UAs of intended users know that 
they are sending incorrect credentials.


As was pointed out before, Asterisk is a mostly application-level 
construct.  Applications usually have some rudimentary means of 
self-defense such as ACLs, but applications are often conceptually 
distinct from the most appropriate means of securing them.  That's 
what firewalls, SBCs, intrusion detection systems, etc. are for.


Your position is equivalent to saying that stock SSH should not return 
authentication errors for invalid passwords.  The proper solution to 
dictionary attacks is to firewall the SSH service, use RSA keys, VPNs, 
etc., not to tell the maintainers of the OpenSSH project to come to 
its senses.


--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Kevin P. Fleming]

On 07/26/2011 02:14 PM, Alex Balashov wrote:

On 07/26/2011 02:09 PM, CDR wrote:


Only way to cope with hackers would be that Digium comes to its
senses and accepts to disable any response to a REGISTER whose
username is unknown. I cannot think of a good reason why Digium
finds this proposal unacceptable, given the onslaught of hacking
that we are seeing in the industry. It may take a single line of
code and it would save millions of $$$. Not only because the
hackers will never get in, but because we would save a huge CPU
impact responding to hundreds of REGISTER attempts per minute. It
is a NO brainer. Can please the Powers that Be reconsider and add
this option to sip.conf? Please?


No, because that's absolutely ridiculous. The proper, RFC-compliant
behaviour is to return an authentication failure in response to invalid
credentials. This mechanism is relied upon for legitimate functionality,
such as letting the UAs of intended users know that they are sending
incorrect credentials.

As was pointed out before, Asterisk is a mostly application-level
construct. Applications usually have some rudimentary means of
self-defense such as ACLs, but applications are often conceptually
distinct from the most appropriate means of securing them. That's what
firewalls, SBCs, intrusion detection systems, etc. are for.

Your position is equivalent to saying that stock SSH should not return
authentication errors for invalid passwords. The proper solution to
dictionary attacks is to firewall the SSH service, use RSA keys, VPNs,
etc., not to tell the maintainers of the OpenSSH project to come to its
senses.


Two additional points to the ones Alex already made:

* We *must* behave identically for any REGISTER request, regardless of 
whether the requested URI represents a 'known' or an 'unknown' address 
of record (user). If that is not done, then it's easy for an attacker to 
learn which usernames *are* valid, and focus their dictionary attack 
efforts on those usernames.


* The processing workload in Asterisk for a REGISTER request is to 
parse, validate and process it, *not* sending the failure (or 
'authentication required') response. Making Asterisk not send the 
response would *not* cause hackers to stop sending masses of REGISTER 
requests; once they have *any* reason to suspect that a particular IP 
address/port combination has a SIP registrar listening on it, they'll 
attack it.


--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com  www.asterisk.org

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Bruce B]

I would have to err on the side of CDR to say that the only difference in
analogy you provided (SSH vs Asterisk) is that people lose much more
 in VoIP than they ever did in SSH hacking. So, if this is an
exceptional case bending a rule or two of RFC in favor of security won't
harm specially if it's provided as an option. After-all, RFC does stand for
Referral For Comment as in always open to be improved. Secondly, there is no
trade off with the responses as local and private IP networks are well know
from the public range so the option for such a security measure can be tuned
to be smart to that end.

The only thing I like about MS OSs is that it's secure out of box and that
is really what a Linux OS should be as well but it's not and so it's not
solely Digium's issue and I see your point giving the analogy.

I think it's a good idea if such a security option is provided by default
in Asterisk knowing it can save a lot of headache. If budget is an issue
maybe make it a bounty and watch support pouring in...

- Bruce

On Tue, Jul 26, 2011 at 2:14 PM, Alex Balashov abalas...@evaristesys.comwrote:

 On 07/26/2011 02:09 PM, CDR wrote:

  Only way to cope with hackers would be that Digium comes to its
 senses and accepts to disable any response to a REGISTER whose
 username is unknown.  I cannot think of a good reason why Digium
 finds this proposal unacceptable, given the onslaught of hacking
 that we are seeing in the industry. It may take a single line of
 code and it would save millions of $$$. Not only because the
 hackers will never get in, but because we would save a huge CPU
 impact responding to hundreds of REGISTER attempts per minute. It
 is a NO brainer. Can please the Powers that Be reconsider and add
 this option to sip.conf? Please?


 No, because that's absolutely ridiculous.  The proper, RFC-compliant
 behaviour is to return an authentication failure in response to invalid
 credentials.  This mechanism is relied upon for legitimate functionality,
 such as letting the UAs of intended users know that they are sending
 incorrect credentials.

 As was pointed out before, Asterisk is a mostly application-level
 construct.  Applications usually have some rudimentary means of self-defense
 such as ACLs, but applications are often conceptually distinct from the most
 appropriate means of securing them.  That's what firewalls, SBCs, intrusion
 detection systems, etc. are for.

 Your position is equivalent to saying that stock SSH should not return
 authentication errors for invalid passwords.  The proper solution to
 dictionary attacks is to firewall the SSH service, use RSA keys, VPNs, etc.,
 not to tell the maintainers of the OpenSSH project to come to its senses.

 --
 Alex Balashov - Principal
 Evariste Systems LLC
 260 Peachtree Street NW
 Suite 2200
 Atlanta, GA 30303
 Tel: +1-678-954-0670
 Fax: +1-404-961-1892
 Web: http://www.evaristesys.com/


 --
 __**__**_
 -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Alex Balashov]

On 07/26/2011 02:33 PM, Bruce B wrote:


I would have to err on the side of CDR to say that the only difference
in analogy you provided (SSH vs Asterisk) is that people lose much
more  in VoIP than they ever did in SSH hacking. So, if this
is an exceptional case bending a rule or two of RFC in favor of
security won't harm specially if it's provided as an
option.


Again:

_Applications are often conceptually distinct from the most 
appropriate means of securing them._


Moreover, as Kevin Fleming pointed out, refraining from responding to 
invalid credentials while continuing to responding to valid ones 
simply shifts the presentation of the information, from the point of 
view of the scanner.  It doesn't accomplish your goal at all.



After-all, RFC does stand for Referral For Comment as in always
open to be improved.


Adopted ones are standards to be followed.

You're right, though;  the IETF SIP working group welcomes incremental 
improvements;  submit yours and see what they think.  If you get your 
draft adopted, I am sure Digium would be more than happy to implement 
it in chan_sip.



I think it's a good idea if such a security option is provided by
default in Asterisk knowing it can save a lot of headache. If
budget is an issue maybe make it a bounty and watch support pouring
in...


The issue is not lack of resources, but rather that it's conceptually 
incorrect behaviour, and that the UAS is the wrong place to solve this 
problem.


The best advice that has been given in relation to this topic so far 
came from Lee Howard earlier today:


http://lists.digium.com/pipermail/asterisk-users/2011-July/265012.html

--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[arcopix]

Hello all,

Just out of curiosity, why are you not using something like fail2ban.
It tends to work flawlessly against brute force attacks. It works 
good on invalid registrations / invites / etc.

You can go pretty much fanatic with that tool (ban IP addr for a week
if
they fail to register more than 6 times).

What you are proposing is not hard to be achieved but it won't
introduce
any improvement in the security of any protocol supported by Asterisk.

Regards,
Stefan Lekov

On Tue, 26 Jul 2011 14:42:01 -0400, Alex Balashov
abalas...@evaristesys.com wrote:
 On 07/26/2011 02:33 PM, Bruce B wrote:
 
 I would have to err on the side of CDR to say that the only difference
 in analogy you provided (SSH vs Asterisk) is that people lose much
 more  in VoIP than they ever did in SSH hacking. So, if this
 is an exceptional case bending a rule or two of RFC in favor of
 security won't harm specially if it's provided as an
 option.
 
 Again:
 
 _Applications are often conceptually distinct from the most
 appropriate means of securing them._
 
 Moreover, as Kevin Fleming pointed out, refraining from responding to
 invalid credentials while continuing to responding to valid ones
 simply shifts the presentation of the information, from the point of
 view of the scanner.  It doesn't accomplish your goal at all.
 
 After-all, RFC does stand for Referral For Comment as in always
 open to be improved.
 
 Adopted ones are standards to be followed.
 
 You're right, though;  the IETF SIP working group welcomes
 incremental improvements;  submit yours and see what they think.  If
 you get your draft adopted, I am sure Digium would be more than happy
 to implement it in chan_sip.
 
 I think it's a good idea if such a security option is provided by
 default in Asterisk knowing it can save a lot of headache. If
 budget is an issue maybe make it a bounty and watch support pouring
 in...
 
 The issue is not lack of resources, but rather that it's conceptually
 incorrect behaviour, and that the UAS is the wrong place to solve this
 problem.
 
 The best advice that has been given in relation to this topic so far
 came from Lee Howard earlier today:
 
 http://lists.digium.com/pipermail/asterisk-users/2011-July/265012.html
 
 -- 
 Alex Balashov - Principal
 Evariste Systems LLC
 260 Peachtree Street NW
 Suite 2200
 Atlanta, GA 30303
 Tel: +1-678-954-0670
 Fax: +1-404-961-1892
 Web: http://www.evaristesys.com/
 
 --
 _
 -- 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


--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Steve Edwards]

On Tue, 26 Jul 2011, Bruce B wrote:

After-all, RFC does stand for Referral For Comment as in always open to 
be improved.


Actually, it stands for 'Request' and I don't think Digium or the Asterisk 
mailing lists made the request :)


Maybe the proper path is for you to submit a comment to the responsible 
parties and see if you can get any traction there.


Failing that, if your unfunded requests for this feature fall on deaf ears 
on the mailing list, maybe a bounty would help.


I don't think having each application (Asterisk, SSH, Apache, MySQL, etc.) 
handle security in an incompatible way is going to advance the state of 
security.


As long as the application can be configured to log what you consider a 
security event, you have the ability to implement whichever security 
policies make sense to you.


Why do you find the 'fail2ban' and 'iptables' suggestions insufficient?

--
Thanks in advance,
-
Steve Edwards   sedwa...@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

Re: [asterisk-users] Securing Asterisk

[Richard Kenner]

 Can please the Powers that Be reconsider and add this option to sip.conf?

What Powers that Be?  This is open-source software!  If you need an
option in sip.conf, just add it!

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Alex Balashov]

On 07/26/2011 03:51 PM, Richard Kenner wrote:


Can please the Powers that Be reconsider and add this option to sip.conf?


What Powers that Be?  This is open-source software!  If you need an
option in sip.conf, just add it!


Or don't.  Just because it's open source doesn't mean you should put 
dumb stuff in there that doesn't belong.



--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Paul Belanger]

On 11-07-26 02:33 PM, Bruce B wrote:

I would have to err on the side of CDR to say that the only difference in
analogy you provided (SSH vs Asterisk) is that people lose much more
 in VoIP than they ever did in SSH hacking. So, if this is an
exceptional case bending a rule or two of RFC in favor of security won't
harm specially if it's provided as an option. After-all, RFC does stand for
Referral For Comment as in always open to be improved. Secondly, there is no
trade off with the responses as local and private IP networks are well know
from the public range so the option for such a security measure can be tuned
to be smart to that end.

The only thing I like about MS OSs is that it's secure out of box and that
is really what a Linux OS should be as well but it's not and so it's not
solely Digium's issue and I see your point giving the analogy.

I think it's a good idea if such a security option is provided by default
in Asterisk knowing it can save a lot of headache. If budget is an issue
maybe make it a bounty and watch support pouring in...

ProTip: Nothing is 'secure out of box' and believe this marketing 
tag-line only provides a false sense of security.


Even if the community does as you ask, it would not guarantee security. 
 Good security required upkeep and maintenance.


As an example, what version of Asterisk are you running on your 
production sites?


--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com  http://asterisk.org

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Alex Balashov]

On Jul 26, 2011, at 2:33 PM, Bruce B bruceb...@gmail.com wrote:

 people lose much more  in VoIP than they ever did in SSH hacking.

Um, what?

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Paul Hayes]

On 23/07/11 04:48, Bruce B wrote:


Quote,/How do the users register to begin with, if their REGISTER
requests won't be processed unless their IP is already known to be a
registrant?  :-)/

Well, unfortunately I don't have the luxury of knowing their IP and the
closest I know is their IP range.



Then I don't understand what the point would be.  You'll have to leave 
Asterisk responding to all Register requests (and to be fair all the 
attacks I've seen have been done by sending Register requests anyway).


I use OSSEC on my Asterisk systems to handle iptables rule generation on 
the fly.  You could write your own rule(s) for that to block source IP 
addresses sending you Invites when they aren't Registered.


cheers,
Paul.

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Alex Balashov]

On 07/23/2011 11:39 PM, C F wrote:


On Sat, Jul 23, 2011 at 1:38 PM, CDRvene...@gmail.com  wrote:

I beg to differ. Digium is hiding from the real world and somebody is


Because you have no clue how to secure a box its someone elses fault?


Of course!  Does Call Detail Record need to repeat himself?

--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Mitesh Thakkar]

I think fail2ban can help in this issue.

Regards,
Mitesh Thakkar
+91 94279 07952
Yahoo: miteshthakkar...@yahoo.co.in
GTalk: mail.mthak...@gmail.com



On Sat, Jul 23, 2011 at 10:04 AM, Bruce B bruceb...@gmail.com wrote:
 Robert thanks for weighing in.
 So, you are saying that FreeSwitch on it's own can tackle issues like this
 without the need of OpenSIPs? Can you elaborate please?
 Thanks

 On Sat, Jul 23, 2011 at 12:17 AM, Robert-iPhone rhuddles...@gmail.com
 wrote:

 I like to put mine on 3389

 hahaha just kidding.

 Personally I'm starting to convert to FreeSwitch - oops I had to say it.

 Security can be difficult and there are some good SBCs out there - just
 begs investment in technology - OH and bright staff


 Sent from my iPhone

 On Jul 23, 2011, at 12:09 AM, Steve Edwards asterisk@sedwards.com
 wrote:

  On Fri, 22 Jul 2011, Bruce B wrote:
 
  1- So, you are saying that either of OpenSER/Kamailio/OpenSIPS actually
  give me the full capability to the SIP stack to do the sort of thing I was
  asking for? And this can run on the same server as Asterisk is running?
 
  Configure OpenSIPS to listen to 5060 and Asterisk to listen to 5061.
 
  --
  Thanks in advance,
 
  -
  Steve Edwards       sedwa...@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

 --
 _
 -- 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


 --
 _
 -- 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


--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Bruce B]

Not really. It's only good after DECLINED is sent.

On Sat, Jul 23, 2011 at 2:08 AM, Mitesh Thakkar mail.mthak...@gmail.comwrote:

 I think fail2ban can help in this issue.

 Regards,
 Mitesh Thakkar
 +91 94279 07952
 Yahoo: miteshthakkar...@yahoo.co.in
 GTalk: mail.mthak...@gmail.com



 On Sat, Jul 23, 2011 at 10:04 AM, Bruce B bruceb...@gmail.com wrote:
  Robert thanks for weighing in.
  So, you are saying that FreeSwitch on it's own can tackle issues like
 this
  without the need of OpenSIPs? Can you elaborate please?
  Thanks
 
  On Sat, Jul 23, 2011 at 12:17 AM, Robert-iPhone rhuddles...@gmail.com
  wrote:
 
  I like to put mine on 3389
 
  hahaha just kidding.
 
  Personally I'm starting to convert to FreeSwitch - oops I had to say it.
 
  Security can be difficult and there are some good SBCs out there - just
  begs investment in technology - OH and bright staff
 
 
  Sent from my iPhone
 
  On Jul 23, 2011, at 12:09 AM, Steve Edwards asterisk@sedwards.com
  wrote:
 
   On Fri, 22 Jul 2011, Bruce B wrote:
  
   1- So, you are saying that either of OpenSER/Kamailio/OpenSIPS
 actually
   give me the full capability to the SIP stack to do the sort of thing
 I was
   asking for? And this can run on the same server as Asterisk is
 running?
  
   Configure OpenSIPS to listen to 5060 and Asterisk to listen to 5061.
  
   --
   Thanks in advance,
  
  
 -
   Steve Edwards   sedwa...@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
 
  --
  _
  -- 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
 
 
  --
  _
  -- 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
 

 --
 _
 -- 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

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Paul Belanger]

On 11-07-23 12:34 AM, Bruce B wrote:

Robert thanks for weighing in.

So, you are saying that FreeSwitch on it's own can tackle issues like this
without the need of OpenSIPs? Can you elaborate please?

If true, I'd be curious to see how they accomplish it.  I've never tried 
FreeSwitch but as more and more people mention it I should take some 
time to play with it.


However, from a SIP point of view, not replying to an INVITE message is 
not an option according to the SIP RFC[1]


13.3.1.3 The INVITE is Rejected

   A common scenario occurs when the callee is currently not willing or
   able to take additional calls at this end system.  A 486 (Busy Here)
   SHOULD be returned in such a scenario.  If the UAS knows that no
   other end system will be able to accept this call, a 600 (Busy
   Everywhere) response SHOULD be sent instead.  However, it is unlikely
   that a UAS will be able to know this in general, and thus this
   response will not usually be used.  The response is passed to the
   INVITE server transaction, which will deal with its retransmissions.

   A UAS rejecting an offer contained in an INVITE SHOULD return a 488
   (Not Acceptable Here) response.  Such a response SHOULD include a
   Warning header field value explaining why the offer was rejected.

[1] http://www.ietf.org/rfc/rfc3261.txt

--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com  http://asterisk.org

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Patrick Lists]

On 07/23/2011 04:00 PM, Paul Belanger wrote:

A UAS rejecting an offer contained in an INVITE SHOULD return a 488
(Not Acceptable Here) response. Such a response SHOULD include a
Warning header field value explaining why the offer was rejected.


If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC 
created by people who had no appreciation for the rather ugly world out 
there then why not throw the RFC out of the window and *not* reject an 
invite with a 488? It sounds like an interesting option to add to 
10/trunk. Better secure than compliant  sorry. Why not do a little 
Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with their 
interpretation of SIP.


Regards,
Patrick

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Paul Belanger]

On 11-07-23 11:48 AM, Patrick Lists wrote:

On 07/23/2011 04:00 PM, Paul Belanger wrote:

A UAS rejecting an offer contained in an INVITE SHOULD return a 488
(Not Acceptable Here) response. Such a response SHOULD include a
Warning header field value explaining why the offer was rejected.


If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC
created by people who had no appreciation for the rather ugly world out
there then why not throw the RFC out of the window and *not* reject an
invite with a 488? It sounds like an interesting option to add to
10/trunk. Better secure than compliant  sorry. Why not do a little
Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with their
interpretation of SIP.

Personally, I don't see this as a solutions.  SIP already provides some 
ability to help with security (EG: TLS, SRTP) however that is basically 
the extent of it.


The way I see it, it is outside the scope of SIP; it's a signaling 
protocol. If 'security' is really something you want to establish, many 
existing tools are available to handle this (EG: VPN, firewalls, 
encryption, etc).


As previously mentioned, there is no easy, simple solution. Securing 
ones services takes work (and time) to do it right.  Most people don't 
want to spend the effort monitoring it.


--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com  http://asterisk.org

--
_
-- 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

[asterisk-users] Securing Asterisk

[CDR]

 Message-ID:
        2584e1abc3629c4d85a61b8dc4d27297096f1...@exchangelu.lu.cybernet.local

 Content-Type: text/plain; charset=us-ascii

 Hi all,

 I need help for make a pattern for a special case that i can't find the 
 solution.

 In my case I want to match these in one pattern:

 This is the same ext that can come in 4 cases

 exten = _42704701,1,Macro(dialfax,${EXTEN:-8})         ; case with 42704701
 exten = _X42704701,1,Macro(dialfax,${EXTEN:-8})                ; case with 
 042704701
 exten = _42704701,1,Macro(dialfax,${EXTEN:-8})     ; case with 
 +3242704701
 exten = _XXX42704701,1,Macro(dialfax,${EXTEN:-8})              ; case with 
 3242704701

 I have try _.42704701 but the parser stop to check after the point .    :-(

 So did you have any suggestion ?

 Regards

 Armand Fumal




 --

 Message: 3
 Date: Sat, 23 Jul 2011 17:48:44 +0200
 From: Patrick Lists asterisk-l...@puzzled.xs4all.nl
 Subject: Re: [asterisk-users] Securing Asterisk - How to avoid
        sending, SIP/2.0 603 Declined
 To: Asterisk Users Mailing List - Non-Commercial Discussion
        asterisk-users@lists.digium.com
 Message-ID: 4e2aed5c.9080...@puzzled.xs4all.nl
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 On 07/23/2011 04:00 PM, Paul Belanger wrote:
 A UAS rejecting an offer contained in an INVITE SHOULD return a 488
 (Not Acceptable Here) response. Such a response SHOULD include a
 Warning header field value explaining why the offer was rejected.

 If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC
 created by people who had no appreciation for the rather ugly world out
 there then why not throw the RFC out of the window and *not* reject an
 invite with a 488? It sounds like an interesting option to add to
 10/trunk. Better secure than compliant  sorry. Why not do a little
 Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with their
 interpretation of SIP.

 Regards,
 Patrick



 --

 Message: 4
 Date: Sat, 23 Jul 2011 12:07:49 -0400
 From: Paul Belanger pabelan...@digium.com
 Subject: Re: [asterisk-users] Securing Asterisk - How to avoid
        sending, SIP/2.0 603 Declined
 To: asterisk-users@lists.digium.com
 Message-ID: 4e2af1d5.80...@digium.com
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 On 11-07-23 11:48 AM, Patrick Lists wrote:
 On 07/23/2011 04:00 PM, Paul Belanger wrote:
 A UAS rejecting an offer contained in an INVITE SHOULD return a 488
 (Not Acceptable Here) response. Such a response SHOULD include a
 Warning header field value explaining why the offer was rejected.

 If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC
 created by people who had no appreciation for the rather ugly world out
 there then why not throw the RFC out of the window and *not* reject an
 invite with a 488? It sounds like an interesting option to add to
 10/trunk. Better secure than compliant  sorry. Why not do a little
 Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with their
 interpretation of SIP.

 Personally, I don't see this as a solutions.  SIP already provides some
 ability to help with security (EG: TLS, SRTP) however that is basically
 the extent of it.

 The way I see it, it is outside the scope of SIP; it's a signaling
 protocol. If 'security' is really something you want to establish, many
 existing tools are available to handle this (EG: VPN, firewalls,
 encryption, etc).

 As previously mentioned, there is no easy, simple solution. Securing
 ones services takes work (and time) to do it right.  Most people don't
 want to spend the effort monitoring it.

 --
 Paul Belanger
 Digium, Inc. | Software Developer
 twitter: pabelanger | IRC: pabelanger (Freenode)
 Check us out at: http://digium.com  http://asterisk.org



 --

 ___
 --Bandwidth and Colocation Provided by http://www.api-digital.com--

 AstriCon 2010 - October 26-28 Washington, DC
 Register Now: http://www.astricon.net/

 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

 End of asterisk-users Digest, Vol 84, Issue 44
 **


--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Darren Wiebe]

 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




--

Message: 2
Date: Sat, 23 Jul 2011 14:30:42 +
From: Armand Fumala...@cybernet.lu
Subject: [asterisk-users] dialplan pattern help
To: asterisk-users@lists.digium.com
asterisk-users@lists.digium.com
Message-ID:
2584e1abc3629c4d85a61b8dc4d27297096f1...@exchangelu.lu.cybernet.local

Content-Type: text/plain; charset=us-ascii

Hi all,

I need help for make a pattern for a special case that i can't find the 
solution.

In my case I want to match these in one pattern:

This is the same ext that can come in 4 cases

exten =  _42704701,1,Macro(dialfax,${EXTEN:-8}) ; case with 42704701
exten =  _X42704701,1,Macro(dialfax,${EXTEN:-8}); case with 
042704701
exten =  _42704701,1,Macro(dialfax,${EXTEN:-8}) ; case with +3242704701
exten =  _XXX42704701,1,Macro(dialfax,${EXTEN:-8})  ; case with 
3242704701

I have try _.42704701 but the parser stop to check after the point .:-(

So did you have any suggestion ?

Regards

Armand Fumal




--

Message: 3
Date: Sat, 23 Jul 2011 17:48:44 +0200
From: Patrick Listsasterisk-l...@puzzled.xs4all.nl
Subject: Re: [asterisk-users] Securing Asterisk - How to avoid
sending, SIP/2.0 603 Declined
To: Asterisk Users Mailing List - Non-Commercial Discussion
asterisk-users@lists.digium.com
Message-ID:4e2aed5c.9080...@puzzled.xs4all.nl
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 07/23/2011 04:00 PM, Paul Belanger wrote:

A UAS rejecting an offer contained in an INVITE SHOULD return a 488
(Not Acceptable Here) response. Such a response SHOULD include a
Warning header field value explaining why the offer was rejected.

If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC
created by people who had no appreciation for the rather ugly world out
there then why not throw the RFC out of the window and *not* reject an
invite with a 488? It sounds like an interesting option to add to
10/trunk. Better secure than compliant  sorry. Why not do a little
Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with their
interpretation of SIP.

Regards,
Patrick



--

Message: 4
Date: Sat, 23 Jul 2011 12:07:49 -0400
From: Paul Belangerpabelan...@digium.com
Subject: Re: [asterisk-users] Securing Asterisk - How to avoid
sending, SIP/2.0 603 Declined
To: asterisk-users@lists.digium.com
Message-ID:4e2af1d5.80...@digium.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 11-07-23 11:48 AM, Patrick Lists wrote:

On 07/23/2011 04:00 PM, Paul Belanger wrote:

A UAS rejecting an offer contained in an INVITE SHOULD return a 488
(Not Acceptable Here) response. Such a response SHOULD include a
Warning header field value explaining why the offer was rejected.

If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC
created by people who had no appreciation for the rather ugly world out
there then why not throw the RFC out of the window and *not* reject an
invite with a 488? It sounds like an interesting option to add to
10/trunk. Better secure than compliant  sorry. Why not do a little
Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with their
interpretation of SIP.


Personally, I don't see this as a solutions.  SIP already provides some
ability to help with security (EG: TLS, SRTP) however that is basically
the extent of it.

The way I see it, it is outside the scope of SIP; it's a signaling
protocol. If 'security' is really something you want to establish, many
existing tools are available to handle this (EG: VPN, firewalls,
encryption, etc).

As previously mentioned, there is no easy, simple solution. Securing
ones services takes work (and time) to do it right.  Most people don't
want to spend the effort monitoring it.

--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com;  http://asterisk.org



--

___
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2010 - October 26-28 Washington, DC
Register Now: http://www.astricon.net/

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

End of asterisk-users Digest, Vol 84, Issue 44
**


--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Paul Belanger]

On 11-07-23 01:38 PM, CDR wrote:

I beg to differ. Digium is hiding from the real world and somebody is
going take the software and run with it. My customers lost in excess
of $50.000 and cut my pay in half, because of hackers. The hackers
figured out how to scan every asterisk for weak passwords or open
ports, and bang them real good. We need two things: a) disable in
sip.conf the reply for INVITES that have wrong user information, and
also, b) disable any response to any REGISTER packet altogether. Can
somebody please write  patch? Or should we go broke trying to stop the
flood of criminals coming from abroad?
Federico

I'm not sure I understand your statement.  Because your customer was 
hacked for $50,000 and your pay was cut in half, it is a result of 
Digium (or the Asterisk project) 'hiding from the real world'?


Your previous point aside, may I ask how your client solved the problem? 
 I'm assuming they are still operating an Asterisk box without the 
patches you have requested.


--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com  http://asterisk.org

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Danny Nicholas]

Simple economics tells me that we can't pay enough guys $X U.S. to stop the
problem when we are competing with multiple folks working for $0.X US.
Asterisk isn't the problem, it's just another limb on the victim tree.

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Paul Belanger
Sent: Saturday, July 23, 2011 1:10 PM
To: asterisk-users@lists.digium.com
Subject: Re: [asterisk-users] Securing Asterisk

On 11-07-23 01:38 PM, CDR wrote:
 I beg to differ. Digium is hiding from the real world and somebody is 
 going take the software and run with it. My customers lost in excess 
 of $50.000 and cut my pay in half, because of hackers. The hackers 
 figured out how to scan every asterisk for weak passwords or open 
 ports, and bang them real good. We need two things: a) disable in 
 sip.conf the reply for INVITES that have wrong user information, and 
 also, b) disable any response to any REGISTER packet altogether. Can 
 somebody please write  patch? Or should we go broke trying to stop the 
 flood of criminals coming from abroad?
 Federico

I'm not sure I understand your statement.  Because your customer was hacked
for $50,000 and your pay was cut in half, it is a result of Digium (or the
Asterisk project) 'hiding from the real world'?

Your previous point aside, may I ask how your client solved the problem? 
  I'm assuming they are still operating an Asterisk box without the patches
you have requested.

--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode) Check us out at:
http://digium.com  http://asterisk.org

--
_
-- 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


--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Robert-iPhone]

Such a pointless argument. The same problem can happen on any voip platform 
including freeswitch.
Again it's a knowledge thing.
BTW if you were paying attention to your logs or practiced good admin skills 
you would have seen the attacks and stopped them.
I swear by fail2ban and other hardening techniques. If you honestly think you 
can just run the box out in the open after running a yum / apt or
rpm command you are in the wrong position.
Know this is going to sound harsh but you deserve the pay cut if not 
termination.


Sent from my iPhone

On Jul 23, 2011, at 2:13 PM, Danny Nicholas da...@debsinc.com wrote:

 Simple economics tells me that we can't pay enough guys $X U.S. to stop the
 problem when we are competing with multiple folks working for $0.X US.
 Asterisk isn't the problem, it's just another limb on the victim tree.
 
 -Original Message-
 From: asterisk-users-boun...@lists.digium.com
 [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Paul Belanger
 Sent: Saturday, July 23, 2011 1:10 PM
 To: asterisk-users@lists.digium.com
 Subject: Re: [asterisk-users] Securing Asterisk
 
 On 11-07-23 01:38 PM, CDR wrote:
 I beg to differ. Digium is hiding from the real world and somebody is 
 going take the software and run with it. My customers lost in excess 
 of $50.000 and cut my pay in half, because of hackers. The hackers 
 figured out how to scan every asterisk for weak passwords or open 
 ports, and bang them real good. We need two things: a) disable in 
 sip.conf the reply for INVITES that have wrong user information, and 
 also, b) disable any response to any REGISTER packet altogether. Can 
 somebody please write  patch? Or should we go broke trying to stop the 
 flood of criminals coming from abroad?
 Federico
 
 I'm not sure I understand your statement.  Because your customer was hacked
 for $50,000 and your pay was cut in half, it is a result of Digium (or the
 Asterisk project) 'hiding from the real world'?
 
 Your previous point aside, may I ask how your client solved the problem? 
  I'm assuming they are still operating an Asterisk box without the patches
 you have requested.
 
 --
 Paul Belanger
 Digium, Inc. | Software Developer
 twitter: pabelanger | IRC: pabelanger (Freenode) Check us out at:
 http://digium.com  http://asterisk.org
 
 --
 _
 -- 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
 
 
 --
 _
 -- 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

--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[Eric Wieling]

 -Original Message-
 From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-
 boun...@lists.digium.com] On Behalf Of CDR
 Sent: Saturday, July 23, 2011 1:39 PM
 To: asterisk-users@lists.digium.com
 Subject: [asterisk-users] Securing Asterisk
 
 I beg to differ. Digium is hiding from the real world and somebody is going
 take the software and run with it. My customers lost in excess of $50.000 and
 cut my pay in half, because of hackers. The hackers figured out how to scan
 every asterisk for weak passwords or open ports, and bang them real good.
 We need two things: a) disable in sip.conf the reply for INVITES that have
 wrong user information, and also, b) disable any response to any REGISTER
 packet altogether. Can somebody please write  patch? Or should we go
 broke trying to stop the flood of criminals coming from abroad?
 Federico

We use fail2ban to prevent brute force password hacking.We don't allow weak 
passwords.This isn't rocket science.



--
_
-- 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

Re: [asterisk-users] Securing Asterisk

[C F]

 --

 Message: 2
 Date: Sat, 23 Jul 2011 14:30:42 +
 From: Armand Fumal a...@cybernet.lu
 Subject: [asterisk-users] dialplan pattern help
 To: asterisk-users@lists.digium.com
        asterisk-users@lists.digium.com
 Message-ID:
        
 2584e1abc3629c4d85a61b8dc4d27297096f1...@exchangelu.lu.cybernet.local

 Content-Type: text/plain; charset=us-ascii

 Hi all,

 I need help for make a pattern for a special case that i can't find the 
 solution.

 In my case I want to match these in one pattern:

 This is the same ext that can come in 4 cases

 exten = _42704701,1,Macro(dialfax,${EXTEN:-8})         ; case with 42704701
 exten = _X42704701,1,Macro(dialfax,${EXTEN:-8})                ; case with 
 042704701
 exten = _42704701,1,Macro(dialfax,${EXTEN:-8})     ; case with 
 +3242704701
 exten = _XXX42704701,1,Macro(dialfax,${EXTEN:-8})              ; case with 
 3242704701

 I have try _.42704701 but the parser stop to check after the point .    :-(

 So did you have any suggestion ?

 Regards

 Armand Fumal




 --

 Message: 3
 Date: Sat, 23 Jul 2011 17:48:44 +0200
 From: Patrick Lists asterisk-l...@puzzled.xs4all.nl
 Subject: Re: [asterisk-users] Securing Asterisk - How to avoid
        sending, SIP/2.0 603 Declined
 To: Asterisk Users Mailing List - Non-Commercial Discussion
        asterisk-users@lists.digium.com
 Message-ID: 4e2aed5c.9080...@puzzled.xs4all.nl
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 On 07/23/2011 04:00 PM, Paul Belanger wrote:
 A UAS rejecting an offer contained in an INVITE SHOULD return a 488
 (Not Acceptable Here) response. Such a response SHOULD include a
 Warning header field value explaining why the offer was rejected.

 If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC
 created by people who had no appreciation for the rather ugly world out
 there then why not throw the RFC out of the window and *not* reject an
 invite with a 488? It sounds like an interesting option to add to
 10/trunk. Better secure than compliant  sorry. Why not do a little
 Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with their
 interpretation of SIP.

 Regards,
 Patrick



 --

 Message: 4
 Date: Sat, 23 Jul 2011 12:07:49 -0400
 From: Paul Belanger pabelan...@digium.com
 Subject: Re: [asterisk-users] Securing Asterisk - How to avoid
        sending, SIP/2.0 603 Declined
 To: asterisk-users@lists.digium.com
 Message-ID: 4e2af1d5.80...@digium.com
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 On 11-07-23 11:48 AM, Patrick Lists wrote:
 On 07/23/2011 04:00 PM, Paul Belanger wrote:
 A UAS rejecting an offer contained in an INVITE SHOULD return a 488
 (Not Acceptable Here) response. Such a response SHOULD include a
 Warning header field value explaining why the offer was rejected.

 If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC
 created by people who had no appreciation for the rather ugly world out
 there then why not throw the RFC out of the window and *not* reject an
 invite with a 488? It sounds like an interesting option to add to
 10/trunk. Better secure than compliant  sorry. Why not do a little
 Microsoft Embrace  Extent? Like e.g. Sonus and Cisco do with their
 interpretation of SIP.

 Personally, I don't see this as a solutions.  SIP already provides some
 ability to help with security (EG: TLS, SRTP) however that is basically
 the extent of it.

 The way I see it, it is outside the scope of SIP; it's a signaling
 protocol. If 'security' is really something you want to establish, many
 existing tools are available to handle this (EG: VPN, firewalls,
 encryption, etc).

 As previously mentioned, there is no easy, simple solution. Securing
 ones services takes work (and time) to do it right.  Most people don't
 want to spend the effort monitoring it.

 --
 Paul Belanger
 Digium, Inc. | Software Developer
 twitter: pabelanger | IRC: pabelanger (Freenode)
 Check us out at: http://digium.com  http://asterisk.org



 --

 ___
 --Bandwidth and Colocation Provided by http://www.api-digital.com--

 AstriCon 2010 - October 26-28 Washington, DC
 Register Now: http://www.astricon.net/

 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

 End of asterisk-users Digest, Vol 84, Issue 44
 **


 --
 _
 -- 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


--
_
-- Bandwidth

[asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Bruce B]

Hello,

I am wondering if there is a way to drop SIP packets for generic
transactions? For example, only SIP PEERs are allowed to call in and receive
ACK or Declined rather that those inviting a call who are not PEERs at all.

Currently my Asterisk setup sends, *SIP/2.0 603 Declined *to any stranger
invites because my dialplan includes Hangup(). Is there any way I can not
send a 603 declined so to mislead the probe runner?

Thanks
--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Alex Balashov]

On 07/22/2011 07:32 PM, Bruce B wrote:

Hello,

I am wondering if there is a way to drop SIP packets for generic
transactions? For example, only SIP PEERs are allowed to call in and
receive ACK or Declined rather that those inviting a call who are not
PEERs at all.

Currently my Asterisk setup sends, *SIP/2.0 603 Declined *to any
stranger invites because my dialplan includes Hangup(). Is there any
way I can not send a 603 declined so to mislead the probe runner?


There is really no way to accomplish that except with a firewall.


--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Bruce B]

Thanks for the input. I am really surprised. But yes, I want exactly what
firewall does, DROP packet instead of REJECTING it.

So, you are saying that one has to tamper the SIP stack to add the option to
not respond to un-trusted sources?
I really thought Asterisk might have this built in as a feature.


I can't even do a dialplan search for a registered PEER because even if I
find the IP to not be a trusted I still need to Hangup() on the invite which
in turn send 603 Declined.

There isn't really any work-around to this?

Thanks again


On Fri, Jul 22, 2011 at 7:39 PM, Alex Balashov abalas...@evaristesys.comwrote:

 On 07/22/2011 07:32 PM, Bruce B wrote:

 Hello,

 I am wondering if there is a way to drop SIP packets for generic
 transactions? For example, only SIP PEERs are allowed to call in and
 receive ACK or Declined rather that those inviting a call who are not
 PEERs at all.

 Currently my Asterisk setup sends, *SIP/2.0 603 Declined *to any
 stranger invites because my dialplan includes Hangup(). Is there any
 way I can not send a 603 declined so to mislead the probe runner?


 There is really no way to accomplish that except with a firewall.


 --
 Alex Balashov - Principal
 Evariste Systems LLC
 260 Peachtree Street NW
 Suite 2200
 Atlanta, GA 30303
 Tel: +1-678-954-0670
 Fax: +1-404-961-1892
 Web: http://www.evaristesys.com/

 --
 __**__**_
 -- 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-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Alex Balashov]

Asterisk does not expose low-level control of its SIP stack.  It's something 
intended to be configured and used at the application level.

If you really want to do this without a firewall, put a Kamailio proxy in front 
of your Asterisk install and drop things as you see fit.  But why go through 
the trouble?  What's wrong with iptables?

--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

On Jul 22, 2011, at 9:30 PM, Bruce B bruceb...@gmail.com wrote:

 Thanks for the input. I am really surprised. But yes, I want exactly what 
 firewall does, DROP packet instead of REJECTING it.
 
 So, you are saying that one has to tamper the SIP stack to add the option to 
 not respond to un-trusted sources?
 I really thought Asterisk might have this built in as a feature.
 
 
 I can't even do a dialplan search for a registered PEER because even if I 
 find the IP to not be a trusted I still need to Hangup() on the invite which 
 in turn send 603 Declined. 
 
 There isn't really any work-around to this?
 
 Thanks again
 
 
 On Fri, Jul 22, 2011 at 7:39 PM, Alex Balashov abalas...@evaristesys.com 
 wrote:
 On 07/22/2011 07:32 PM, Bruce B wrote:
 Hello,
 
 I am wondering if there is a way to drop SIP packets for generic
 transactions? For example, only SIP PEERs are allowed to call in and
 receive ACK or Declined rather that those inviting a call who are not
 PEERs at all.
 
 Currently my Asterisk setup sends, *SIP/2.0 603 Declined *to any
 stranger invites because my dialplan includes Hangup(). Is there any
 way I can not send a 603 declined so to mislead the probe runner?
 
 There is really no way to accomplish that except with a firewall.
 
 
 -- 
 Alex Balashov - Principal
 Evariste Systems LLC
 260 Peachtree Street NW
 Suite 2200
 Atlanta, GA 30303
 Tel: +1-678-954-0670
 Fax: +1-404-961-1892
 Web: http://www.evaristesys.com/
 
 --
 _
 -- 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
 
 --
 _
 -- 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
--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Paul Belanger]

On 11-07-22 07:32 PM, Bruce B wrote:

Hello,

I am wondering if there is a way to drop SIP packets for generic
transactions? For example, only SIP PEERs are allowed to call in and receive
ACK or Declined rather that those inviting a call who are not PEERs at all.

Currently my Asterisk setup sends, *SIP/2.0 603 Declined *to any stranger
invites because my dialplan includes Hangup(). Is there any way I can not
send a 603 declined so to mislead the probe runner?


Have you tried disabling guests?

sip.conf
[general]
allowguest=no

--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com  http://asterisk.org

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Alex Balashov]

Paul,

Won't that just send a 403 Forbidden?

--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

On Jul 22, 2011, at 9:48 PM, Paul Belanger pabelan...@digium.com wrote:

 On 11-07-22 07:32 PM, Bruce B wrote:
 Hello,
 
 I am wondering if there is a way to drop SIP packets for generic
 transactions? For example, only SIP PEERs are allowed to call in and receive
 ACK or Declined rather that those inviting a call who are not PEERs at all.
 
 Currently my Asterisk setup sends, *SIP/2.0 603 Declined *to any stranger
 invites because my dialplan includes Hangup(). Is there any way I can not
 send a 603 declined so to mislead the probe runner?
 
 Have you tried disabling guests?
 
 sip.conf
 [general]
 allowguest=no
 
 -- 
 Paul Belanger
 Digium, Inc. | Software Developer
 twitter: pabelanger | IRC: pabelanger (Freenode)
 Check us out at: http://digium.com  http://asterisk.org
 
 --
 _
 -- 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

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Paul Belanger]

On 11-07-22 09:51 PM, Alex Balashov wrote:

Paul,

Won't that just send a 403 Forbidden?

I believe so, but I was proposing a different SIP message then 603 
Declined.  As you mentioned, a firewall is the real solution if OP wants 
to drop packets.


Asterisk is a B2BUA, not a firewall.

--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com  http://asterisk.org

--
_
-- 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

Re: [asterisk-users] Securing Asterisk - How to avoid sending, SIP/2.0 603 Declined

[Bruce B]

Robert thanks for weighing in.

So, you are saying that FreeSwitch on it's own can tackle issues like this
without the need of OpenSIPs? Can you elaborate please?

Thanks

On Sat, Jul 23, 2011 at 12:17 AM, Robert-iPhone rhuddles...@gmail.comwrote:

 I like to put mine on 3389

 hahaha just kidding.

 Personally I'm starting to convert to FreeSwitch - oops I had to say it.

 Security can be difficult and there are some good SBCs out there - just
 begs investment in technology - OH and bright staff


 Sent from my iPhone

 On Jul 23, 2011, at 12:09 AM, Steve Edwards asterisk@sedwards.com
 wrote:

  On Fri, 22 Jul 2011, Bruce B wrote:
 
  1- So, you are saying that either of OpenSER/Kamailio/OpenSIPS actually
 give me the full capability to the SIP stack to do the sort of thing I was
 asking for? And this can run on the same server as Asterisk is running?
 
  Configure OpenSIPS to listen to 5060 and Asterisk to listen to 5061.
 
  --
  Thanks in advance,
  -
  Steve Edwards   sedwa...@sedwards.com  Voice: +1-760-468-3867PST
  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

 --
 _
 -- 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

--
_
-- 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

Re: [asterisk-users] Securing Asterisk and your network

[Jay R. Ashworth]

On Thu, Jun 12, 2008 at 11:09:43PM +0300, Tzafrir Cohen wrote:
  Additionally, you should install a brute-force-attack blocker:
  
  http://www.la-samhna.de/library/brutessh.html
 
 This is effectively another service listening. It is also a method for
 an attacker to lock you out of the system.
 
 See, for instance, http://www.ossec.net/en/attacking-loganalysis.html .

Sure; all in-band methods suffer from the possibility of becoming DoS
vectors.  And yes, the fact that sshd doesn't quote that argument as it
drops it into the syslog, making it easier to see bogusness, is a bad
thing.  But those log lines wouldn't fool *me*.

And if they fool your log analysis system, then it's regexes aren't
written tightly enough.

And, back on point, that particular sshblocker doesn't give a damn what
sshd writes in the syslog.

And, no, it's actually not another service listening.

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Joseph Stalin)

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Securing Asterisk and your network

[Tzafrir Cohen]

On Fri, Jun 13, 2008 at 11:51:35AM -0400, Jay R. Ashworth wrote:
 On Thu, Jun 12, 2008 at 11:09:43PM +0300, Tzafrir Cohen wrote:
   Additionally, you should install a brute-force-attack blocker:
   
   http://www.la-samhna.de/library/brutessh.html
  
  This is effectively another service listening. It is also a method for
  an attacker to lock you out of the system.
  
  See, for instance, http://www.ossec.net/en/attacking-loganalysis.html .
 
 Sure; all in-band methods suffer from the possibility of becoming DoS
 vectors.  And yes, the fact that sshd doesn't quote that argument as it
 drops it into the syslog, making it easier to see bogusness, is a bad
 thing.  But those log lines wouldn't fool *me*.
 
 And if they fool your log analysis system, then it's regexes aren't
 written tightly enough.

Aparantly, getting the regex right is a bit trickier than people think.

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4321
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6302

So getting this regex right is probably a bit tricky.

 
 And, back on point, that particular sshblocker doesn't give a damn what
 sshd writes in the syslog.
 
 And, no, it's actually not another service listening.

It responds to external output. I can trigger it to run whenever I want.
Pretty close to a service.

Consider e.g. a spam filter used by a mail server. It might just as well
have such remotely-exploitable security holes, if badly written. And the
attacker does not even need direct access to the system running the spam
filter.

Or Asterisk handling proxied SIP/IAX traffic.

-- 
   Tzafrir Cohen
icq#16849755  jabber:[EMAIL PROTECTED]
+972-50-7952406   mailto:[EMAIL PROTECTED]
http://www.xorcom.com  iax:[EMAIL PROTECTED]/tzafrir

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Securing Asterisk and your network

[Jay R. Ashworth]

On Fri, Jun 13, 2008 at 08:43:44PM +0300, Tzafrir Cohen wrote:
  And if they fool your log analysis system, then it's regexes aren't
  written tightly enough.
 
 Aparantly, getting the regex right is a bit trickier than people think.
 
 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4321
 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6302
 
 So getting this regex right is probably a bit tricky.

That can happen.

  And, back on point, that particular sshblocker doesn't give a damn what
  sshd writes in the syslog.
  
  And, no, it's actually not another service listening.
 
 It responds to external output. I can trigger it to run whenever I want.
 Pretty close to a service.

Except that it's invisible to the outside world; it's a side-effect of
sshd, without even it's own port.

 Consider e.g. a spam filter used by a mail server. It might just as well
 have such remotely-exploitable security holes, if badly written. And the
 attacker does not even need direct access to the system running the spam
 filter.
 
 Or Asterisk handling proxied SIP/IAX traffic.

Sure, in general, being very particular about the taintedness of your
data is an important security practice...

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Joseph Stalin)

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Securing Asterisk and your network

[Jay R. Ashworth]

On Thu, Jun 12, 2008 at 08:41:18AM -0500, Lyle Giese wrote:
Most recent hacks that I have first or second hand knowledge of
came from ssh issues. Most inexperienced admins will expose ssh
without using the 'allowgroups' option in their sshd_config and
will get hacked by someone logging in via ssh using a system
account with no password. The second thing to do with ssh is to
move it to another port to keep the script kiddies from pounding on
it. If there is a weak or missing password, they will find it.


This is true, and I'd forgotten to mention it.

Update your machine regularly, and always take security updates, even
if they cause breakage you have to chase down.

Additionally, you should install a brute-force-attack blocker:

http://www.la-samhna.de/library/brutessh.html

I like the tcp_wrappers version, but whatever suits you.

An encrypted USB thumbdrive is also a good storage device for
passwords. I use TrueCrypt and have the executable availble
unencrypted on the thumbdrive so I could plug it into almost any
machine and get to the encrypted data.

Though note that all currently extant hardware-secured thumbdrives are
snake oil.

I recommend Bruce Schneier's Password Safe (and not any of the other,
similarly named programs) if you feel the need to store a lot of
authentication credentials.  Or get a BlackBerry and use theirs.

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Joseph Stalin)

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Securing Asterisk and your network

[Tzafrir Cohen]

On Thu, Jun 12, 2008 at 09:53:53AM -0400, Jay R. Ashworth wrote:

 Additionally, you should install a brute-force-attack blocker:
 
 http://www.la-samhna.de/library/brutessh.html

This is effectively another service listening. It is also a method for
an attacker to lock you out of the system.

See, for instance, http://www.ossec.net/en/attacking-loganalysis.html .

-- 
   Tzafrir Cohen
icq#16849755  jabber:[EMAIL PROTECTED]
+972-50-7952406   mailto:[EMAIL PROTECTED]
http://www.xorcom.com  iax:[EMAIL PROTECTED]/tzafrir

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users