Topic: Asterisk and Firewall Issue

[edeganay]

Hello,
I have an interesting issue.
SME 7.4 and Selintra contrib
I just changed my sip provider to a new (cheaper) one.
Everything is (almost) fine, except a constant error message on the asterisk log and CLI
chan_sip.c:6797 determine_firstline_parts: Bad request protocol Packet

The SIP Provider knows it, ans propose a solution :
iptables -A INPUT -p udp -m udp --dport 5060 -m string --string "Cirpack KeepAlive Packet" --algo bm --to 65535 --source SIPProviderAddress -j DROP

I know that doing this will be done untill SME reboot, how to add this permanently ?

More over, when pasting the commande to SME commandline, I have the following error

iptables v1.2.11: Couldn't load match `string':/lib/iptables/libipt_string.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.



any idea to what to do ?

Edd

[arne]

First of all I thinkt the Linux firewall configurartion command can not be correct for any Linux/Asterisk serverr because it will place the rule at the bottom at the rule stack where it anyhow will have no effect.

(You can not first allow all UDP 5060 packets to pass out of the rule stack, and then block the remaining 0 ip packets that have a certain string content. Any percent of 0 blocked packets will still be zero packets.)

Second, I think that firewall module that make inspection on packet string content is not a standard module in most Linux distros. So to use it will anyhow require a distro that has this particular kernel module included into the kernel (or that can load it dynamically.)

So I guess that this IPABLES configuration command will now work at all.

May be it is a good idea to move this question to the Selintra "iptelephony department" ?

Bay the way I think that the SME server like the most other Linux distros has the /etc/rc.local script, but I think in this case it will not help. 

[CharlieBrady]

I have an interesting issue.
SME 7.4 and Selintra contrib

Off-topic for this forum, which concerns only software installed from the SME server CD.

[arne]

But it could be a "pure" Selintra server question and not a firewall question.

[CharlieBrady]

But it could be a "pure" Selintra server question and not a firewall question.

Yes it could. As I said, off-topic. Unless you think somehow that Selintra software is on the SME server install CD.

arne, I wish you would think more and write less.

[chris burnat]

Moving to VOIP/Selintra where it is more appropriate

[SARK devs]

Well, we tried.

Sorry you didn't get an answer Ed.

This may help...

http://wiki.contribs.org/Firewall

Good luck

S

[edeganay]

ok guys, I'm going there,
Thank's anyway, but Selintra sent me to here.

Edd

[chris burnat]

We have a bit of a mix-up here...

Edd, presumably guided by Sak Dev (hello guys!) is attempting to add a rule into the firewall to fix an issue with SARK:

Code: [Select]

iptables -A INPUT -p udp -m udp --dport 5060 -m string --string "Cirpack KeepAlive Packet" --algo bm --to 65535 --source SIPProviderAddress -j DROP
The question appears to be: "How to achieve this"?  Please correct me if incorrect.

And a twist: when pasting the command to SME commandline, the return is:

Code: [Select]

iptables v1.2.11: Couldn't load match `string':/lib/iptables/libipt_string.so: cannot open shared object file: No such file or directory
I do not have sufficient expertise to guide anyone in this jungle, perhaps one of the Devs checking the Forums may provide some guidance to this user and our good friends at SAIL/Sark.
Thanks.


Addentum:  Went through some of the early installation of Sail, we had to modify the firewall and JonM had provided a method to do this here: http://contribs.org/modules/pbboard/viewtopic.php?p=131691#131691
Unfortunately, this link is now dead. 

Copy of my notes at the time:
1) Create custom template

Code: [Select]

mkdir -p /etc/e-smith/templates-custom/etc/rc.d/init.d/masq
cd /etc/e-smith/templates-custom/etc/rc.d/init.d/masq
pico 90InboundUDP20rtp_udp

2) Copy/paste new rule
3) save and apply by issuing the following command from CL:
signal-event remoteaccess-update

You can check with iptables -L. 
Food for thoughts, no warranty. If it works, the final mod should take into account "the database driven nature of the current
configuration system".

[edeganay]

thanks chris

[CharlieBrady]

More over, when pasting the commande to SME commandline, I have the following error

iptables v1.2.11: Couldn't load match `string':/lib/iptables/libipt_string.so: cannot open shared object file: No such file or directory

As arne pointed out, the 'string' module is not part of the iptables/netfilter installation on SME server. You cannot use that rule with SME server, unless you work out how to build and install the 'string' module.

Since you have a problem with the selintra contrib, you should report the problem in the bug tracker, and the developers of the contrib will work with you there to determine a fix or a workaround.

[edeganay]

duely noted,
however, as it's the Telephony provider who gave me the solution, it seems that it appear to any asterisk server, not only selintra.
I'll try to find my way...alone.

Thank's anyway
Edd

[arne]

The solution diven by the iptelephony provider should not work on most Linux/Asterisk servers.

Reason:

1. The Netfilter string filtering module will have to be included in the kernel. I believe this is not the case for most mainstream Linux distros.

2. The iptables command/configuration line will only work at a Linux server with an empty set of firewall rules as the supplied suggestion will not work togheter with an active firewall, with other firewall rules, already applied.

So there will need to be a Linux installation with a specialized firewall module compiled into the kernel, and with the firewall left completely open.

The reason that the Asterisk server give som error messages is that the server of the iptelephony provider sends out some requests to the Asterisk server, that the Asterisk server with this particular configuration will not accept.


So I guess the problem can be solved in two or tree different ways: 

1. The server of the iptelephony provider has to stop sending out this incorrect or non Asterisk server compatible request.

2. Possibly the best alternative: The local Asterisk server has to be reconfigured in some way so it will ignore the inccompatible request. (Possibly corrections in the sip.conf file.)

3. The difficult alternative: A firewall has to filter out the incompatible request using a string filtering function.


If the name og the iptelephony provider is posted here, I/We could try to look into if there is some technical datas that could support alternative 2.

It wouldn't surprice me if Selintra had some bether proposals than me conserning alternative 2.

(What seems to be the case is that the iptelephony providers server sees the Asterisk server as some kind of sip client, and not a server, so it sends some kind of KeepAllive packets to this expected sip client, that the Asterisk server will not accept.)

I'm sure that those working on the Selintra/Sail project knows a lot more than me on this subject, and that they could correct me or fill out the information.

[edeganay]

Arne,
Let me tell you something, you're good
The sip provider is very possibly seeing my server as a client.

Selintra guys, any idea ?

Thanks a lot anyway !
Edd

[arne]

Well ofcourse your server is in some way a client to the providers server, but the trafic that is generated in a typical client to server "scenario" might not be the same as for a "server to server/proxy" scenario.

I think that such a "keep allive request" from server to client, should normally not be there in a typical server to server/proxy setup, while it looks like it is there for this particular provider.

The suggested sulution from the provider is to filter it out. This is a rather unusual solution I think, as it will not work on most Linux servers, as suggested from the provider.

Hopefully there is someone at "support team" that knows how to set up Asterisk server to ignore this keep alive request. (Because it should not be there and it can not be filtered out unless you replace the SME server kernel.)

*****

Some more info, hopefully to work on:

https://issues.asterisk.org/view.php?id=9816

http://lists.digium.com/pipermail/asterisk-dev/2006-May/021033.html

http://lists.digium.com/pipermail/asterisk-dev/2006-May/021035.html

http://readlist.com/lists/lists.digium.com/asterisk-users/13/69458.html

But this solution will not work for most Asterisk servers unless with a unstandard kernel:

http://readlist.com/lists/lists.digium.com/asterisk-users/13/69480.html