Is there a way for FS not to send back any response to INVITE
Hi, In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions. I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily. The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the *respond* dialplan app. However, that might encourage the scanner to keep trying. So I guess there are two questions: 1. Is there a way not to send back 100 Trying at all? 2. Is there a way to not send any final response?
I think you can write a dialplan module for the first question. Mike or Anthony can confirm this.
On 1 de jun de 2016, at 16:40, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Hi,
In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions.
I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily.
The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the respond dialplan app. However, that might encourage the scanner to keep trying.
So I guess there are two questions:
1. Is there a way not to send back 100 Trying at all?
2. Is there a way to not send any final response? _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Ítalo Rossi italo@freeswitch.org
The only way with our current sip module to accomplish either of these would be to put a sip proxy out front to handle that behavior, or to somehow use iptables to block the traffic
On Jun 1, 2016, at 3:40 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Hi,
In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions.
I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily.
The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the respond dialplan app. However, that might encourage the scanner to keep trying.
So I guess there are two questions:
1. Is there a way not to send back 100 Trying at all?
2. Is there a way to not send any final response?
Thanks guys! IP tables is how we block most traffic but we can only block traffic by port. In this case it's about invalid INVITES coming in on a valid port. Do you think this functionality would be useful? Is it worth opening a feature request and perhaps putting a bounty on it? Any idea of the effort? On Wed, Jun 1, 2016 at 1:00 PM, Michael Jerris <mike@jerris.com> wrote:
The only way with our current sip module to accomplish either of these would be to put a sip proxy out front to handle that behavior, or to somehow use iptables to block the traffic
On Jun 1, 2016, at 3:40 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Hi,
In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions.
I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily.
The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the *respond* dialplan app. However, that might encourage the scanner to keep trying.
So I guess there are two questions:
1. Is there a way not to send back 100 Trying at all?
2. Is there a way to not send any final response?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
If you want to do this, put a proxy out in front... Doing it in freeswitch would require a complete rewrite of the sip module.
On Jun 1, 2016, at 4:05 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Thanks guys! IP tables is how we block most traffic but we can only block traffic by port. In this case it's about invalid INVITES coming in on a valid port.
Do you think this functionality would be useful? Is it worth opening a feature request and perhaps putting a bounty on it? Any idea of the effort?
On Wed, Jun 1, 2016 at 1:00 PM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote: The only way with our current sip module to accomplish either of these would be to put a sip proxy out front to handle that behavior, or to somehow use iptables to block the traffic
On Jun 1, 2016, at 3:40 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com>> wrote:
Hi,
In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions.
I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily.
The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the respond dialplan app. However, that might encourage the scanner to keep trying.
So I guess there are two questions:
1. Is there a way not to send back 100 Trying at all?
2. Is there a way to not send any final response?
Got it, thanks Michael! On Wed, Jun 1, 2016 at 1:11 PM, Michael Jerris <mike@jerris.com> wrote:
If you want to do this, put a proxy out in front... Doing it in freeswitch would require a complete rewrite of the sip module.
On Jun 1, 2016, at 4:05 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Thanks guys! IP tables is how we block most traffic but we can only block traffic by port. In this case it's about invalid INVITES coming in on a valid port.
Do you think this functionality would be useful? Is it worth opening a feature request and perhaps putting a bounty on it? Any idea of the effort?
On Wed, Jun 1, 2016 at 1:00 PM, Michael Jerris <mike@jerris.com> wrote:
The only way with our current sip module to accomplish either of these would be to put a sip proxy out front to handle that behavior, or to somehow use iptables to block the traffic
On Jun 1, 2016, at 3:40 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Hi,
In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions.
I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily.
The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the *respond* dialplan app. However, that might encourage the scanner to keep trying.
So I guess there are two questions:
1. Is there a way not to send back 100 Trying at all?
2. Is there a way to not send any final response?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Oleg, With iptables you can block based on what is inside SIP packet(off cause if you are not using TLS), take a look on link below: http://www.bertera.it/index.php/2014/01/22/sip-facket-filtering-with-iptable... It is not best way to achieve what you need, cause as far as I know it is resource consuming operations. Best way will be to use Kamailio as SIP proxy in front. With kind regards, Jurijs On Wed, Jun 1, 2016 at 11:05 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Thanks guys! IP tables is how we block most traffic but we can only block traffic by port. In this case it's about invalid INVITES coming in on a valid port.
Do you think this functionality would be useful? Is it worth opening a feature request and perhaps putting a bounty on it? Any idea of the effort?
On Wed, Jun 1, 2016 at 1:00 PM, Michael Jerris <mike@jerris.com> wrote:
The only way with our current sip module to accomplish either of these would be to put a sip proxy out front to handle that behavior, or to somehow use iptables to block the traffic
On Jun 1, 2016, at 3:40 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Hi,
In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions.
I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily.
The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the *respond* dialplan app. However, that might encourage the scanner to keep trying.
So I guess there are two questions:
1. Is there a way not to send back 100 Trying at all?
2. Is there a way to not send any final response?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks Jurijs! Unfortunately we do need to use TLS. On Wed, Jun 1, 2016 at 1:26 PM, Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi Oleg,
With iptables you can block based on what is inside SIP packet(off cause if you are not using TLS), take a look on link below:
http://www.bertera.it/index.php/2014/01/22/sip-facket-filtering-with-iptable...
It is not best way to achieve what you need, cause as far as I know it is resource consuming operations. Best way will be to use Kamailio as SIP proxy in front.
With kind regards,
Jurijs
On Wed, Jun 1, 2016 at 11:05 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Thanks guys! IP tables is how we block most traffic but we can only block traffic by port. In this case it's about invalid INVITES coming in on a valid port.
Do you think this functionality would be useful? Is it worth opening a feature request and perhaps putting a bounty on it?
Any idea of the effort?
On Wed, Jun 1, 2016 at 1:00 PM, Michael Jerris <mike@jerris.com> wrote:
The only way with our current sip module to accomplish either of these would be to put a sip proxy out front to handle that behavior, or to somehow use iptables to block the traffic
On Jun 1, 2016, at 3:40 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Hi,
In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions.
I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily.
The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the *respond* dialplan app. However, that might encourage the scanner to keep trying.
So I guess there are two questions:
1. Is there a way not to send back 100 Trying at all?
2. Is there a way to not send any final response?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Keep in mind that with SIP if the server is listening you are supposed to respond. Not responding is a violation of the RFC… now that being side… using DPI via IPTables is a perfect way to dissuade the scanners… and btw, if you are using TLS, they don’t even need to see SIP to know you have something listening on TCP on the SIP port now, you’re syn-ack in reply to their syn already told them that…. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Oleg Stolyar Sent: Wednesday, June 1, 2016 3:39 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Is there a way for FS not to send back any response to INVITE Thanks Jurijs! Unfortunately we do need to use TLS. On Wed, Jun 1, 2016 at 1:26 PM, Jurijs Ivolga <jurijs.ivolga@gmail.com <mailto:jurijs.ivolga@gmail.com> > wrote: Hi Oleg, With iptables you can block based on what is inside SIP packet(off cause if you are not using TLS), take a look on link below: http://www.bertera.it/index.php/2014/01/22/sip-facket-filtering-with-iptable... It is not best way to achieve what you need, cause as far as I know it is resource consuming operations. Best way will be to use Kamailio as SIP proxy in front. With kind regards, Jurijs On Wed, Jun 1, 2016 at 11:05 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com> > wrote: Thanks guys! IP tables is how we block most traffic but we can only block traffic by port. In this case it's about invalid INVITES coming in on a valid port. Do you think this functionality would be useful? Is it worth opening a feature request and perhaps putting a bounty on it? Any idea of the effort? On Wed, Jun 1, 2016 at 1:00 PM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com> > wrote: The only way with our current sip module to accomplish either of these would be to put a sip proxy out front to handle that behavior, or to somehow use iptables to block the traffic On Jun 1, 2016, at 3:40 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com> > wrote: Hi, In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions. I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily. The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the respond dialplan app. However, that might encourage the scanner to keep trying. So I guess there are two questions: 1. Is there a way not to send back 100 Trying at all? 2. Is there a way to not send any final response? _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yep, thanks for the context Ken! On Wed, Jun 1, 2016 at 1:52 PM, Ken Rice <krice@freeswitch.org> wrote:
Keep in mind that with SIP if the server is listening you are supposed to respond. Not responding is a violation of the RFC… now that being side… using DPI via IPTables is a perfect way to dissuade the scanners… and btw, if you are using TLS, they don’t even need to see SIP to know you have something listening on TCP on the SIP port now, you’re syn-ack in reply to their syn already told them that….
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Oleg Stolyar *Sent:* Wednesday, June 1, 2016 3:39 PM *To:* FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Subject:* Re: [Freeswitch-users] Is there a way for FS not to send back any response to INVITE
Thanks Jurijs!
Unfortunately we do need to use TLS.
On Wed, Jun 1, 2016 at 1:26 PM, Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi Oleg,
With iptables you can block based on what is inside SIP packet(off cause if you are not using TLS), take a look on link below:
http://www.bertera.it/index.php/2014/01/22/sip-facket-filtering-with-iptable...
It is not best way to achieve what you need, cause as far as I know it is resource consuming operations. Best way will be to use Kamailio as SIP proxy in front.
With kind regards,
Jurijs
On Wed, Jun 1, 2016 at 11:05 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Thanks guys! IP tables is how we block most traffic but we can only block traffic by port. In this case it's about invalid INVITES coming in on a valid port.
Do you think this functionality would be useful?
Is it worth opening a feature request and perhaps putting a bounty on it?
Any idea of the effort?
On Wed, Jun 1, 2016 at 1:00 PM, Michael Jerris <mike@jerris.com> wrote:
The only way with our current sip module to accomplish either of these would be to put a sip proxy out front to handle that behavior, or to somehow use iptables to block the traffic
On Jun 1, 2016, at 3:40 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Hi,
In order to protect against scanning attacks I'd like for FS to not respond to INVITES unless they match certain conditions.
I understand that currently FS always responds with 100 Trying right away before processing the call and then, if the call does not match anything in the dialplan, responds with a 302 Moved Temporarily.
The 302 can be replaced with another response code (for example 403 Forbidden which is what I am doing now) using the *respond* dialplan app. However, that might encourage the scanner to keep trying.
So I guess there are two questions:
1. Is there a way not to send back 100 Trying at all?
2. Is there a way to not send any final response?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (5)
-
Jurijs Ivolga
-
Ken Rice
-
Michael Jerris
-
Oleg Stolyar
-
Ítalo Rossi