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
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
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
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
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
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
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
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
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)
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
--
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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
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
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
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
[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
...@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
-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
?
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
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
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
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
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
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 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
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
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.
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
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
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.
45 matches
Mail list logo
