iptables rule for ovh

iptables rule for ovh

[Portedaix]

Hello,

QUESTION - SHORT VERSION :
Is there a way to have a rule equivalent to the one below which is for 
kernel 2.6.14 and above,  with a linux kernel 2.6.9 ?
'#iptables -A INPUT -p udp -m udp --dport 5060 -m string --string 
"Cirpack KeepAlive Packet" --algo bm --to 65535 --source sip.ovh.net -j 
DROP'

QUESTION - DETAILED VERSION :

I use a sip telephone line from OVH and run asterisk PBX on a sme linux 
server to connect to it.
The asterisk command line is polluted by an error message.

#chan_sip.c:7289 determine_firstline_parts: Bad request protocol Packet

asterisk debug shows

#<--- SIP read from 91.121.129.17:5060 --->
#Cirpack KeepAlive Packet


I could avoid that by activating the rule

#iptables -A INPUT -p udp -m udp --dport 5060 -m string --string 
"Cirpack KeepAlive Packet" --algo bm --to 65535 --source sip.ovh.net -j DROP

But my main problem is this string module. My kernel is 2.6.9, and 
string module is used starting from 2.6.14 kernel. Upgrading the kernel 
on my production server is not easy, and may lead to a heavy 
reconfiguration. So if I can find a way just to have this rule 
activated, that would be fine.

Thanks in advance for any help.
Olivier

Re: iptables rule for ovh

[Pascal Hambourg]

Hello,

Portedaix a écrit :
> Hello,
> 
> QUESTION - SHORT VERSION :
> Is there a way to have a rule equivalent to the one below which is for
> kernel 2.6.14 and above,  with a linux kernel 2.6.9 ?
> '#iptables -A INPUT -p udp -m udp --dport 5060 -m string --string
> "Cirpack KeepAlive Packet" --algo bm --to 65535 --source sip.ovh.net -j
> DROP'

FWIW, the 'string' match was available for older kernels in the
patch-o-matic-ng up to patch-o-matic-ng-20050918.

Re: iptables rule for ovh

[Richard Horton]

On 29 July 2010 10:08, Portedaix <portedaix@gmail.com> wrote:
>
> Hello,
>
> QUESTION - SHORT VERSION :
> Is there a way to have a rule equivalent to the one below which is for kernel 2.6.14 and above,  with a linux kernel 2.6.9 ?
> '#iptables -A INPUT -p udp -m udp --dport 5060 -m string --string "Cirpack KeepAlive Packet" --algo bm --to 65535 --source sip.ovh.net -j DROP'

Looking on the various asterisk/digium mailing lists etc there are a
number of discussions regarding cirpack - including a number of patchs
for chan_sip.

You might be better off patching chan_sip to handle them rather than discarding.

The other option would be, depending on the headers etc, use something
like the u32 match to discard them.



--
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.pbase.com/arimus - My online photogallery
http://uk.linkedin.com/in/richardhorton1972 - My linkedin profile
http://www.solstans.co.uk/richard - Online CV

Re: iptables rule for ovh

[Pascal Hambourg]

Richard Horton a écrit :
> On 29 July 2010 10:08, Portedaix <portedaix@gmail.com> wrote:
>>
>> Is there a way to have a rule equivalent to the one below which is
>> for kernel 2.6.14 and above,  with a linux kernel 2.6.9 ?
>> '#iptables -A INPUT -p udp -m udp --dport 5060 -m string --string
>> "Cirpack KeepAlive Packet" --algo bm --to 65535 --source sip.ovh.net -j DROP'
[...]
> The other option would be, depending on the headers etc, use something
> like the u32 match to discard them.

The 'u32' match was added in the mainline kernel in version 2.6.23.

Re: iptables rule for ovh

[Jan Engelhardt]

On Thursday 2010-07-29 11:08, Portedaix wrote:
>
> QUESTION - SHORT VERSION :
> Is there a way to have a rule equivalent to the one below which is for kernel
> 2.6.14 and above,  with a linux kernel 2.6.9 ?
> '#iptables -A INPUT -p udp -m udp --dport 5060 -m string --string "Cirpack
> KeepAlive Packet" --algo bm --to 65535 --source sip.ovh.net -j DROP'
>
> I could avoid that by activating the rule
>
> #iptables -A INPUT -p udp -m udp --dport 5060 -m string --string "Cirpack
> KeepAlive Packet" --algo bm --to 65535 --source sip.ovh.net -j DROP
>
> But my main problem is this string module. My kernel is 2.6.9, and string
> module is used starting from 2.6.14 kernel. Upgrading the kernel on my
> production server is not easy, and may lead to a heavy reconfiguration.

Neither of those kernels is supported anymore.
(My credo is: shouldn't have waited until it's completely turned to rust.)

Re: iptables rule for ovh

[Richard Horton]

On 29 July 2010 10:47, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> Neither of those kernels is supported anymore.
> (My credo is: shouldn't have waited until it's completely turned to rust.)

Equally if it isn't broken don't fix it... though in this instance I'd
agree as suspect 2.6.9 lacks a fair few of the security/critical bug
fixes....


-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.pbase.com/arimus - My online photogallery
http://uk.linkedin.com/in/richardhorton1972 - My linkedin profile
http://www.solstans.co.uk/richard - Online CV

Re: iptables rule for ovh

[Portedaix]

Thanks for the answer. I know now what choice I have : compile 
patch-o-matic-ng or go for a new kernel. Probably the second option is 
the wisest.
Regards
Olivier

Le 29/07/2010 11:30, Pascal Hambourg a écrit :
> Hello,
>
> Portedaix a écrit :
>    
>> Hello,
>>
>> QUESTION - SHORT VERSION :
>> Is there a way to have a rule equivalent to the one below which is for
>> kernel 2.6.14 and above,  with a linux kernel 2.6.9 ?
>> '#iptables -A INPUT -p udp -m udp --dport 5060 -m string --string
>> "Cirpack KeepAlive Packet" --algo bm --to 65535 --source sip.ovh.net -j
>> DROP'
>>      
> FWIW, the 'string' match was available for older kernels in the
> patch-o-matic-ng up to patch-o-matic-ng-20050918.
>
>
>    

Re: iptables rule for ovh

[Pascal Hambourg]

Portedaix a écrit :
> Thanks for the answer. I know now what choice I have : compile 
> patch-o-matic-ng or go for a new kernel.

Actually you don't compile the patch-o-matic ; you use it to patch the
kernel source and then you compile a new kernel, or the new module if
applicable.

> Probably the second option is the wisest.

Depends on lots of things. A much more recent kernel may not be
compatible with installed software, requiring other upgrades.