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

[SARK devs]

Selintra guys, any idea ?

Our view hasn't changed.  We'd simply use a different carrier. There are lots to choose from and this is the only one we've ever heard of who requires special firewall rules.

Kind Regards

S

 

[edeganay]

ok no problem, I just wantes to get the thing further
(and actually, it works fine...)

Thanks eveybody, I'll keep you in touch

Edd

[arne]

For later refference and for the full story.

I decided to make a test to try to build in string filtering capability to a SME 8 B4, just to have tested it.

It appeared to be much simpler than expected as the SME 8 B4 actually appear to have the string filtering capability built into its kernel (!!!!)
(So the planned kernel modification for the test were not neccessary to do.)

So I just made a minor adjustment to the command line supplied from the sip telephony vendor:

iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "Cirpack KeepAlive Packet" --algo bm --to 65535 --source 123.123.123.123 -j DROP

And then on the 8.0 B4 it looks like it is just working:

[root@sme8b4 ~]# iptables -L INPUT
Chain INPUT (policy DROP)
target     prot opt source               destination
DROP       udp  --  123.123.123.123      anywhere            udp dpt:5060 STRING match "Cirpack KeepAlive Packet" ALGO name bm TO 65535

As it is showed the rule is on the top where it will have the full effect.

Anyhow I think it would not work for the 7.4, and also it is a much bether choice to change telephony vendor than to use firewall hacks like this.

Also tested Asterisk 1.6 on SME 8 B4 using this guide with some minor modifications: https://asterisk.org/downloads/yum

Looks like it is working ok, and that the SME 8 B4 technically can run both the firewall mod, to do string filtering, and the new Asterisk version that might not have a problem with the KeepAllive request (So there actually might not be any need for filtering at all).

.. Just interesting to find out.
 

[arne]

Just for later refference:

I tried to use the template fragment modification method for the SME 8.0 B4 as mentioned in http://wiki.contribs.org/Firewall "Block incomming ip" and I replaced filtering rule based on source ip with a string/data content filtering rule.

This showed that the SME 8.0 Beta were capable of doing such string/data content filtering based on standard template modifications according to existing procedures for the 7.4.

Technically it should then be possible to block harmfull content from open ports and to apply effective rules like: Open port 80 for all traffic, exept for that traffic with unwanted content ..

This blocking of unwanted content should be possible to do for Asterisk and any other server functions.

It should also be possible to apply other rules for stopping mishaped and spoofed packets via this aditional DenyRiffRaff custom fragment.

Technically it should also be possible to design and apply data content filtering rules that is designed from what you find as hacking atempts and unwanted traffic in the log.

Don't know how such content filtering can put extra load on processor or slow down traffic.

The Asterisk filtering issue for the SME 8.0 B4 should be possible to handle like this:

Custom templates
Block incoming packets with unwanted content
I want to block All traffic from some unwanted data content to my server.
Create a custom template and block data content

mkdir -p /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/
pico -w /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/40DenyRiffRaff

iptables -A INPUT -p udp -m udp --dport 5060 -m string --string "Cirpack KeepAlive Packet" --algo bm --to 65535 --source 123.123.123.123 -j DROP



expand and restart

/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
/etc/init.d/masq restart