log X-AUTH-IP instead of source IP
Hi, I’m using Kamailio as a transparent SIP Proxy in front of my Freeswitch which is configured to use Digest Auth for the clients. I already set up X-AUTH-IP headers on Kamailio and apply-proxy-acl in internal FS profile. To use fail2ban I need to get X-AUTH-IP information instead of source IP in the log messages: --> "SIP auth challenge (INVITE|REGISTER) on sofia profile 'internal' for [xxxxxx] from ip x.x.x.x" (proxy IP) Is there a way to get the original source IP into the SIP auth challenge log message? Thank you for your help!! Best Regards, Roman
Hi Roman, It sounds like you should just attach the original source IP as a custom SIP header on the Kamailio side: append_hf("X-Orig-SRC-IP: $si\r\n"); You can then recover that in FreeSWITCH with ${sip_h_X-Orig-SRC-IP}. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hi Alex, I already get the original source IP into FS but I need to log unsuccessful auth attempts with original IP to block them with fail2ban. The default log message „SIP auth challenge…“ does only log the Proxy IP Roman
Am 29.11.2016 um 09:28 schrieb Alex Balashov <abalashov@evaristesys.com>:
Hi Roman,
It sounds like you should just attach the original source IP as a custom SIP header on the Kamailio side:
append_hf("X-Orig-SRC-IP: $si\r\n");
You can then recover that in FreeSWITCH with ${sip_h_X-Orig-SRC-IP}.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_________________________________________________________________________ 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
On Tue, Nov 29, 2016 at 09:37:26AM +0100, Roman Dissauer wrote:
I already get the original source IP into FS but I need to log unsuccessful auth attempts with original IP to block them with fail2ban. The default log message „SIP auth challenge…“ does only log the Proxy IP
Ah, I see. I must have misunderstood your question, then. It sounds like what you actually want to know is how to issue an arbitrary log statement? I think this page answers that question: https://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_log Or did I miss something still? -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hi Roman, I think that more elegant solution for your task is cut off bruteforce on Kamailio side rather than on FreeSWITCH. You do not need (and must not) pass malicious traffic to backends. It is best practice. Is every inbound requests (REGISTER, INVITE) passes Kamailio? If Kamailio work as stateful SIP proxy then you can pay attention to unsuccessful authentication attempts in reply routes and manages it, for example, with pike or something like that. Or event configure fail2ban on Kamailio server rather than on FreeSWITCH. This is just my opinion. 2016-11-29 10:50 GMT+02:00 Alex Balashov <abalashov@evaristesys.com>:
On Tue, Nov 29, 2016 at 09:37:26AM +0100, Roman Dissauer wrote:
I already get the original source IP into FS but I need to log unsuccessful auth attempts with original IP to block them with fail2ban. The default log message „SIP auth challenge…“ does only log the Proxy IP
Ah, I see.
I must have misunderstood your question, then. It sounds like what you actually want to know is how to issue an arbitrary log statement?
I think this page answers that question:
https://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_log
Or did I miss something still?
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_________________________________________________________________________ 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
-- С уважением, Владислав Захожай
On Tue, Nov 29, 2016 at 11:22:25AM +0200, Vladyslav Zakhozhai wrote:
I think that more elegant solution for your task is cut off bruteforce on Kamailio side rather than on FreeSWITCH. You do not need (and must not) pass malicious traffic to backends. It is best practice.
I would agree with that. Kamailio makes a far better "condom" than Freeswitch. I just assumed there was something in his use-case that compelled relaying traffic forward uncritically. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Thanks guys, I’m sure that it is best practice to prevent brute force attacks on Kamailio. I also do that on another system where Kamailio handles full registration/authentication. Due to the fact that my SIP Proxy is as basic as possible forwarding all packets to the backend Freeswitch (just for load balancing), I thought it would be easier to solve that on Freeswitch side. I’ll try to get that done in the reply route and will post the results here. Roman
Am 29.11.2016 um 10:40 schrieb Alex Balashov <abalashov@evaristesys.com>:
On Tue, Nov 29, 2016 at 11:22:25AM +0200, Vladyslav Zakhozhai wrote:
I think that more elegant solution for your task is cut off bruteforce on Kamailio side rather than on FreeSWITCH. You do not need (and must not) pass malicious traffic to backends. It is best practice.
I would agree with that. Kamailio makes a far better "condom" than Freeswitch.
I just assumed there was something in his use-case that compelled relaying traffic forward uncritically.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_________________________________________________________________________ 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
Roman, My point of view is the following. Fail2ban bans requests based on logs output. Right? You can keep kamailio's config as simple as possible but add logging of failed auth attempts. I.e. reply_route[FROM_BACKEND] { if(status == 403) { xlog("L_WARN", "Frobidden from $si:$sp blah...\n"); } } And then you just need make appropriate filter. This is just my opinion. In the case of FreeSWITCH I do not know is it possible to show original IP address due failed auth attempts. sorry. 2016-11-29 15:08 GMT+02:00 Roman Dissauer <roman@dissauer.net>:
Thanks guys,
I’m sure that it is best practice to prevent brute force attacks on Kamailio. I also do that on another system where Kamailio handles full registration/authentication. Due to the fact that my SIP Proxy is as basic as possible forwarding all packets to the backend Freeswitch (just for load balancing), I thought it would be easier to solve that on Freeswitch side.
I’ll try to get that done in the reply route and will post the results here.
Roman
Am 29.11.2016 um 10:40 schrieb Alex Balashov <abalashov@evaristesys.com :
On Tue, Nov 29, 2016 at 11:22:25AM +0200, Vladyslav Zakhozhai wrote:
I think that more elegant solution for your task is cut off bruteforce on Kamailio side rather than on FreeSWITCH. You do not need (and must not) pass malicious traffic to backends. It is best practice.
I would agree with that. Kamailio makes a far better "condom" than Freeswitch.
I just assumed there was something in his use-case that compelled relaying traffic forward uncritically.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
____________________________________________________________
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
-- С уважением, Владислав Захожай
Are you using apply-proxy-acl? If not see if that helps, otherwise perhaps file a Jira to request it. Regards, Steve On 29 November 2016 at 08:37, Roman Dissauer <roman@dissauer.net> wrote:
Hi Alex,
I already get the original source IP into FS but I need to log unsuccessful auth attempts with original IP to block them with fail2ban. The default log message „SIP auth challenge…“ does only log the Proxy IP
Roman
Am 29.11.2016 um 09:28 schrieb Alex Balashov <abalashov@evaristesys.com :
Hi Roman,
It sounds like you should just attach the original source IP as a custom SIP header on the Kamailio side:
append_hf("X-Orig-SRC-IP: $si\r\n");
You can then recover that in FreeSWITCH with ${sip_h_X-Orig-SRC-IP}.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
____________________________________________________________
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
When you use kamailio then close sip interface port via iptables rules like "block all except kamailio IP where destination port 5060" fail2ban is not required in your case. Failed registration and failed INVITE authorization can be logged at kamailio configuration. ср, 30 нояб. 2016, 0:21 Steven Ayre <steveayre@gmail.com>:
Are you using apply-proxy-acl?
If not see if that helps, otherwise perhaps file a Jira to request it.
Regards, Steve
On 29 November 2016 at 08:37, Roman Dissauer <roman@dissauer.net> wrote:
Hi Alex,
I already get the original source IP into FS but I need to log unsuccessful auth attempts with original IP to block them with fail2ban. The default log message „SIP auth challenge…“ does only log the Proxy IP
Roman
Am 29.11.2016 um 09:28 schrieb Alex Balashov <abalashov@evaristesys.com :
Hi Roman,
It sounds like you should just attach the original source IP as a custom SIP header on the Kamailio side:
append_hf("X-Orig-SRC-IP: $si\r\n");
You can then recover that in FreeSWITCH with ${sip_h_X-Orig-SRC-IP}.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_________________________________________________________________________ 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
Hi, I solved that on Kamailio side: onreply_route { ... if (is_method("REGISTER|INVITE")) { if (pcre_match("$rs", "^4..")) { xlog("L_INFO", "Unauthorized Request from $T_req($si)\n"); } } ... } Thanks! Roman
Am 30.11.2016 um 04:52 schrieb Sergey Safarov <s.safarov@gmail.com>:
When you use kamailio then close sip interface port via iptables rules like "block all except kamailio IP where destination port 5060" fail2ban is not required in your case.
Failed registration and failed INVITE authorization can be logged at kamailio configuration.
ср, 30 нояб. 2016, 0:21 Steven Ayre <steveayre@gmail.com <mailto:steveayre@gmail.com>>: Are you using apply-proxy-acl?
If not see if that helps, otherwise perhaps file a Jira to request it.
Regards, Steve
On 29 November 2016 at 08:37, Roman Dissauer <roman@dissauer.net <mailto:roman@dissauer.net>> wrote: Hi Alex,
I already get the original source IP into FS but I need to log unsuccessful auth attempts with original IP to block them with fail2ban. The default log message „SIP auth challenge…“ does only log the Proxy IP
Roman
Am 29.11.2016 um 09:28 schrieb Alex Balashov <abalashov@evaristesys.com <mailto:abalashov@evaristesys.com>>:
Hi Roman,
It sounds like you should just attach the original source IP as a custom SIP header on the Kamailio side:
append_hf("X-Orig-SRC-IP: $si\r\n");
You can then recover that in FreeSWITCH with ${sip_h_X-Orig-SRC-IP}.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 <tel:%2B1-706-510-6800> (direct) / +1-800-250-5920 <tel:%2B1-800-250-5920> (toll-free) Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>, http://www.csrpswitch.com/ <http://www.csrpswitch.com/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <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 <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <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 <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <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 <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <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)
-
Alex Balashov
-
Roman Dissauer
-
Sergey Safarov
-
Steven Ayre
-
Vladyslav Zakhozhai