CentOS - Aug 2011 - Centos VPS Kernel 2.6.35.4 & 'string-less' IP tables

On a VPS I wanted to add to IP tables:-

iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j DROP

I got:

	iptables: Unknown error 18446744073709551615

uname -a =  2.6.35.4 #2  (don't know how this got installed)

lsmod | grep ipt = ipt_LOG   5419  2 

yum upgrade iptables* = nothing to install.

---------------------------------------

On a standalone server (C 5.6)

iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j DROP

is accepted.

uname -a =  2.6.18-274.el5 #1 

lsmod | grep ipt ipt_LOG                39617  1 
iptable_filter         36161  1 
ip_tables              55457  1 iptable_filter
x_tables               50505  6
xt_string,xt_state,ipt_LOG,xt_tcpudp,ip_tables,ip6_tables

------------------------------------------------

Appreciate suggestions on how to get kernel 2.6.35.4 to install the
whole IP tables package, especially the STRING and RECENT options (in
-m).

Thank you.

Paul.

On 08/31/2011 12:24 PM, Always Learning wrote:
> On a VPS I wanted to add to IP tables:-
>
> iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j
DROP
>
> I got:
>
> 	iptables: Unknown error 18446744073709551615
>
> uname -a =  2.6.35.4 #2  (don't know how this got installed)
I'm wagering that's not the full output of uname -a. As far as I'm 
aware, centos have never shipped a 2.6.35 kernel with any release, and 
that's the sort of error you get with a openVZ "stab" (or Stable) 
kernel, where unless the host provides you with the modules, there's not 
a lot you can do about it.

> <snip>
>
>   Appreciate suggestions on how to get kernel 2.6.35.4 to install the
> whole IP tables package, especially the STRING and RECENT options (in
> -m).
Perhaps you might want to talk to your hosting company about what 
they're selling you, because it certainly isn't a 'pure' centos
install.

Steve.

On Tue, Aug 30, 2011 at 10:24 PM, Always Learning <centos at u61.u22.net>
wrote:
>
> On a VPS I wanted to add to IP tables:-
>
> iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j
DROP
>
> I got:
>
> ? ? ? ?iptables: Unknown error 18446744073709551615
>
> uname -a = ?2.6.35.4 #2 ?(don't know how this got installed)
>
> lsmod | grep ipt = ipt_LOG ? 5419 ?2
>
> uname -a = ?2.6.18-274.el5 #1
You're probably running in an OpenVZ container. You can find out through
http://wiki.openvz.org/BC_proc_entries

Am 31.08.2011 04:24, schrieb Always Learning:
> 
> On a VPS I wanted to add to IP tables:-
> iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j
DROP
> 
> I got:
> 	iptables: Unknown error 18446744073709551615
>
> uname -a =  2.6.35.4 #2  (don't know how this got installed)
> lsmod | grep ipt = ipt_LOG   5419  2 
> yum upgrade iptables* = nothing to install.
I had similar problems back with CentOS 5.4 and non-distro kernel 2.6.32
when I tried to use the MARK target.

The fix was to get a more recent iptables from netfilter.org.
iptables-1.4.7 work for me, currently CentOS 5.6 and kernel 2.6.35.14
in production.

Since I only require the newer iptables command when adding MARK targets
to the mangle table, I've installed netfilter.org iptables to /opt/iptables
and "set export PATH=/opt/iptables/sbin:${PATH}" in scripts where
needed.
Yes, no custom rpm built, just a quick and dirty install to /opt...

FYI, kernels 2.6.32 and 2.6.35 work fine with CentOS 5 except for the
the iptables issue above and a (minor) mcelog problem, IIRC.

Hope that helps,
Walter

PS: To install iptables from source is pretty straightforward:
    get the tarball from netfilter.org, unpack and run:
    ./configure --prefix=/opt/iptables && make && make install

On Tuesday, August 30, 2011 10:24:41 PM Always Learning wrote:
> On a VPS I wanted to add to IP tables:-
> iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j
DROP
> 	iptables: Unknown error 18446744073709551615
> uname -a =  2.6.35.4 #2  (don't know how this got installed)
This is not a CentOS-provided kernel; as has been said elsewhere in the thread,
this is likely an OpenVZ kernel.  Your hosting provider will have to install the
modules necessary to make this function.  If they either cannot or will not,
then you can't use the options you want to use.  The CentOS repositories and
lists are unable to help you with your hosting provider's kernel modules.

Further support may be found either from your provider or from an OpenVZ mailing
list, but OpenVZ container (VPS) support is beyond the scope of this list
because it is so different from 'real' CentOS.

On Wednesday, August 31, 2011 09:18:26 AM Always Learning
wrote:
> A very helpful and knowledgeable poster, Walter Haidinger, in his email
> dated Wed, 31 Aug 2011 13:10:16 +0200 (12:10 BST), gave what appears to
> be an ideal solution.
> 	* get a more recent iptables from netfilter.org
It's less than ideal to install anything from source, as Karanbir has so
correctly pointed out downthread.

Sometimes it is necessary; but it is never ideal, for the reasons KB stated.

Perhaps the most important point here is that the script kiddies and/or 
bots usually make sure the target string, 'login' in your example is
*not*
contained within a single packet.  You can verify this with wireshark.  In 
any case just be aware that your solution will likely not have the desired 
effect.

This a decent read: http://spamcleaner.org/en/misc/w00tw00t.html
Specifically the Conclusion section near the bottom.

On Wed, 31 Aug 2011, Always Learning wrote:
>
> On a VPS I wanted to add to IP tables:-
>
> iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j
DROP
>
> I got:
>
> 	iptables: Unknown error 18446744073709551615
>
> uname -a =  2.6.35.4 #2  (don't know how this got installed)
>
> lsmod | grep ipt = ipt_LOG   5419  2
>
> yum upgrade iptables* = nothing to install.
>
> ---------------------------------------
>
> On a standalone server (C 5.6)
>
> iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j
DROP
>
> is accepted.
>
> uname -a =  2.6.18-274.el5 #1
>
> lsmod | grep ipt > ipt_LOG                39617  1
> iptable_filter         36161  1
> ip_tables              55457  1 iptable_filter
> x_tables               50505  6
> xt_string,xt_state,ipt_LOG,xt_tcpudp,ip_tables,ip6_tables
>
> ------------------------------------------------
>
> Appreciate suggestions on how to get kernel 2.6.35.4 to install the
> whole IP tables package, especially the STRING and RECENT options (in
> -m).
>
> Thank you.
>
> Paul.
>
>

UPDATE:

I started with kernel 2.6.35.4 #2 and lsmod | grep ipt = ipt_LOG 5419  2.

My service provider produced a replacement kernel  2.6.24-28-xen #1.

Now lsmod | grep ipt reveals ......

ipt_LOG                 8192  2 
iptable_filter          4608  1 
ip_tables              24232  1 iptable_filter
x_tables               23432  5 xt_string,ipt_LOG,xt_state,xt_tcpudp,ip_tables

and, to my personal joy and pleasure,

iptables -A XXXX -p tcp -m string --algo bm --string 'login' -j DROP

is accepted by IP Tables.

Thank you to everyone who contributed to this thread.

With best regards,

Paul.

On Wednesday, August 31, 2011 11:15:20 AM Always Learning
wrote:
> Dangerous to ignore any background noise - far better to
> firmly shut the door and fill-in all known holes. 
The unknown holes are the ones that will get you.

You are also setting yourself up for a denial-of-service vector.  Refresh
yourself on the three-way TCP handshake and how HTTP is embedded in that and be
enlightened (IOW, there is a connection allready set up and a listener thread
connected by the time the GET HTTP directive is issued).  Also understand that
IP address spoofing is fairly common... and within the reach of the most green
script kiddie.

The fail2ban solution, while it is somewhat of a 'shut the barn door after
the horses are out' thing, is less likely to cause a DoS.  And it will
likely prevent escalation, which is what you're really after.

Plus, you'll want to see how much of a load the string matching at the
IPtables level puts on your VPS; it may be enough to create a DoS vector there,
too.

On today's Internet you are simply not going to catch 100% of the attacks,
full stop.  You can mitigate them (SELinux is one tool in the mitigation
arsenal, as is fail2ban and IPtables).  But that is all.  You will be attacked;
that is axiomatic on today's Internet.

On Wednesday, August 31, 2011 01:33:31 PM Always Learning
wrote:
> Rather than being a willing or passive victim to 100% of the attacks, I
> aim to reduce the penetrability of most of them.
Getting the last 10% will cost you 90% of your time.