FAQ
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.

Search Discussions

  • Steve Walsh at Aug 30, 2011 at 11:02 pm

    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.
  • Always Learning at Aug 30, 2011 at 11:07 pm

    On Wed, 2011-08-31 at 13:02 +1000, Steve Walsh wrote:

    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.
    Centos 6 is, I believe, 2.6.32, so 2.6.35 is something strange. Google
    shows that version in many data centres.
    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.
    Have already done that. I'm getting about 6,000 web hits a day (all
    wrong URLs) from a lunatic who I can stop in IP Tables but only if the
    alleged Centos version is up-to-date.

    Thank you.

    Paul.
  • John R. Dennison at Aug 30, 2011 at 11:11 pm

    On Wed, Aug 31, 2011 at 04:07:44AM +0100, Always Learning wrote:
    Have already done that. I'm getting about 6,000 web hits a day (all
    wrong URLs) from a lunatic who I can stop in IP Tables but only if the
    alleged Centos version is up-to-date.
    Has nothing to do with being up-to-date; it has to do with no having the
    necessary iptables facilities available. Talk to your hoster.




    John
    --
    In today's online world, what your mother told you is true, only more so:
    people really can judge you by your friends.

    -- Harold Abelson, MIT computer science professor, on personal information
    that can be gleaned from social networking sites, NY Times, 17 March 2010
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110830/0a36a7d4/attachment.bin
  • Always Learning at Aug 30, 2011 at 11:17 pm

    On Tue, 2011-08-30 at 22:11 -0500, John R. Dennison wrote:
    On Wed, Aug 31, 2011 at 04:07:44AM +0100, Always Learning wrote:

    Have already done that. I'm getting about 6,000 web hits a day (all
    wrong URLs) from a lunatic who I can stop in IP Tables but only if the
    alleged Centos version is up-to-date.
    Has nothing to do with being up-to-date; it has to do with no having the
    necessary iptables facilities available. Talk to your hoster.
    NO I will not. I have already emailed them.

    The necessary IP Tables facilities are not available. Therefore,
    contrary to your strange assertion "Has nothing to do with being
    up-to-date" that IP Tables version is certain OUT-OF-DATE because the
    modern parts have not been included !!!

    Have a nice day.

    Paul.
  • John R. Dennison at Aug 30, 2011 at 11:22 pm

    On Wed, Aug 31, 2011 at 04:17:36AM +0100, Always Learning wrote:
    NO I will not. I have already emailed them.
    Then you won't get the support. Period.
    The necessary IP Tables facilities are not available. Therefore,
    contrary to your strange assertion "Has nothing to do with being
    up-to-date" that IP Tables version is certain OUT-OF-DATE because the
    modern parts have not been included !!!
    It's not out of date. OpenVZ / "stab" kernels don't support all ipt-*
    modules by default; they have to be configured on a container basis.

    You can argue and be wrong or you can contact your hoster and have the
    modules you need enabled or you can find an alternate provider. The
    choice is yours.




    John
    --
    The ability to focus attention on important things is a defining
    characteristic of intelligence.

    -- Robert J. Shiller (1946-), American economist, academic, and author,
    Irrational Exuberance (2006)
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110830/5b5b9552/attachment.bin
  • Always Learning at Aug 30, 2011 at 11:30 pm

    On Tue, 2011-08-30 at 22:22 -0500, John R. Dennison wrote:
    On Wed, Aug 31, 2011 at 04:17:36AM +0100, Always Learning wrote:

    NO I will not. I have already emailed them.
    Then you won't get the support. Period.
    Utter rubbish. They are excellent either by phone or by email.
    It's not out of date. OpenVZ / "stab" kernels don't support all ipt-*
    modules by default; they have to be configured on a container basis.

    You can argue and be wrong or you can contact your hoster and have the
    modules you need enabled or you can find an alternate provider. The
    choice is yours.
    Thank you for informing me the 'choice' is mine. Without such undoubted
    inspirational wisdom I would never have known I had a choice. I am most
    grateful to you.

    How many occasions must I state I have emailed the service company
    before you refrain from telling me to contact the "hoster" ?

    Have a peaceful and relaxing evening and a very nice day tomorrow.


    Paul.
  • John R. Dennison at Aug 30, 2011 at 11:41 pm

    On Wed, Aug 31, 2011 at 04:30:37AM +0100, Always Learning wrote:
    Thank you for informing me the 'choice' is mine. Without such undoubted
    inspirational wisdom I would never have known I had a choice. I am most
    grateful to you.
    The choice is indeed yours. You can 1) listen to those that know what
    they are talking about and probably have 50 years of combined experience;
    or 2) remain in the dark and clueless.
    How many occasions must I state I have emailed the service company
    before you refrain from telling me to contact the "hoster" ?
    How many times must you argue when you ask for assistance [1] and have it
    provided for you, free of charge.

    If you want help at least be willing to consider the answers you are
    given and not discount them out of hand because they don't fit the way
    you wish things were.

    [1] "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)."




    John
    --
    Creativity is allowing oneself to make mistakes. Art is knowing which ones
    to keep.

    -- Scott Adams (1957-), American cartoonist and satirist,
    The Dilbert Principle (1996)
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110830/85104dcb/attachment.bin
  • Always Learning at Aug 30, 2011 at 11:54 pm

    On Tue, 2011-08-30 at 22:41 -0500, John R. Dennison wrote:

    The choice is indeed yours.
    Thanks for confirming that again. Its really nice of you to keep
    reminding me.
    You can 1) listen to those that know what
    they are talking about and probably have 50 years of combined experience;
    or 2) remain in the dark and clueless.
    However good my hearing I have to admit that I can't hear you. I can
    read your typing but I honestly can't hear you. Can you shout a little
    louder and I'll listen very quietly ?
    How many times must you argue when you ask for assistance [1] and have it
    provided for you, free of charge.
    Argue ? You told me to talk to someone. I said 'no' because I had
    already emailed them and received a Ticket number. Surely it should be
    my choice how I communicate with a third party ?
    If you want help at least be willing to consider the answers you are
    given and not discount them out of hand because they don't fit the way
    you wish things were.
    I always carefully consider answers and suggestions regardless of the
    source.
    [1] "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)."
    Gee that is nice of you. But at the time I posted my problem I was not
    aware 'the whole IP Tables package' had not been installed because I had
    tried to install it using yum which reported nothing to install.


    Paul.
  • John R. Dennison at Aug 31, 2011 at 12:08 am

    On Wed, Aug 31, 2011 at 04:54:33AM +0100, Always Learning wrote:
    Thanks for confirming that again. Its really nice of you to keep
    reminding me.
    Sigh.

    Can you please stop barking? Your need to get the last word in on EVERY
    thread is more than a little annoying. Just to end this, you can be
    "right" if you want, it's fine by me.




    John

    --
    Technology makes it possible for people to gain control over everything,
    except over technology.

    -- John Tudor
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110830/a372b095/attachment.bin
  • Always Learning at Aug 31, 2011 at 12:11 am

    On Tue, 2011-08-30 at 23:08 -0500, John R. Dennison wrote:

    Sigh.

    Can you please stop barking?
    Are you a dog lover ? I like dogs too. They usually bark at strangers.

    Paul.
  • Michael Schumacher at Aug 31, 2011 at 3:11 am

    Are you a dog lover ? I like dogs too. They usually bark at strangers.
    Paul.
    PLONK




    see also http://en.wikipedia.org/wiki/Plonk_%28Usenet%29

    best regards
    ---
    Michael
  • Steve Walsh at Aug 30, 2011 at 11:30 pm

    On 08/31/2011 01:17 PM, Always Learning wrote:
    NO I will not. I have already emailed them.
    wow....just...wow.
    The necessary IP Tables facilities are not available. Therefore,
    contrary to your strange assertion "Has nothing to do with being
    up-to-date" that IP Tables version is certain OUT-OF-DATE because the
    modern parts have not been included !!!
    They have not been included, probably because you are running an openVZ
    'stab' kernel. Failing to give us the complete output in your initial
    post means that anyone helping you is taking blind guesses. As an
    example, here is the output of uname -a on my C6.0 system;

    Linux omg.wtf.bbq.lol.au 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27
    19:49:27 BST 2011 x86_64 x86_64 x86_64 GNU/Linux

    As you can see, it has a little bit more information that the output of
    the uname -a command you included in your original

    If I google "iptables on openvz", I get the following link from their
    wiki - http://wiki.openvz.org/Setting_up_an_iptables_firewall, have you
    tried that path?

    But, without the full information to start with, it's all conjecture.

    Steve
  • Always Learning at Aug 30, 2011 at 11:43 pm

    On Wed, 2011-08-31 at 13:30 +1000, Steve Walsh wrote:

    They have not been included, probably because you are running an openVZ
    'stab' kernel. Failing to give us the complete output in your initial
    post means that anyone helping you is taking blind guesses.
    That you for the useful enlightenment. I was unaware it was an OpenVZ. I
    thought is was XEN on Ubuntu.
    As an example, here is the output of uname -a on my C6.0 system;

    Linux omg.wtf.bbq.lol.au 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27
    19:49:27 BST 2011 x86_64 x86_64 x86_64 GNU/Linux

    As you can see, it has a little bit more information that the output
    of he uname -a command you included in your original
    Well I cut-out the unnecessary parts and produced a uname -r.
    It was the kernel version that interested me. I just happened to know it
    is 'Linux' and 'GNU' so did not need a reminder.
    If I google "iptables on openvz", I get the following link from their
    wiki - http://wiki.openvz.org/Setting_up_an_iptables_firewall, have you
    tried that path?
    Of course not. My telepathy does not extend beyond half-way down Africa.
    If I have known, but I did not know then, about Open VZ then I would
    have typed that into Google.
    But, without the full information to start with, it's all conjecture.
    I note from your web site you are in to marriage guidance too.

    Have a nice day.

    Paul.
  • Tru Huynh at Aug 31, 2011 at 4:14 am

    On Wed, Aug 31, 2011 at 04:43:46AM +0100, Always Learning wrote:
    That you for the useful enlightenment. I was unaware it was an OpenVZ. I
    thought is was XEN on Ubuntu.
    Next time, try posting more usefull information stating that you are indeed
    running CentOS on a CentOS support mailing list and not some other voices.
    http://wiki.centos.org/irc_centos_request

    3. Kernel Version and CentOS Release
    ...

    http://wiki.centos.org/AdditionalResources/OtherVoices
    Well I cut-out the unnecessary parts and produced a uname -r.
    It was the kernel version that interested me. I just happened to know it
    is 'Linux' and 'GNU' so did not need a reminder.
    full output not what *you* think is enough.

    Tru
    --
    Tru Huynh (mirrors, CentOS i386/x86_64 Package Maintenance)
    http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110831/f9572432/attachment.bin
  • Tom H at Aug 31, 2011 at 4:43 am

    On Tue, Aug 30, 2011 at 10: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)

    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
  • Walter Haidinger at Aug 31, 2011 at 7:10 am

    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
  • Karanbir Singh at Aug 31, 2011 at 9:35 am

    On 08/31/2011 12:10 PM, Walter Haidinger wrote:
    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
    And at that point you lose. All management capability or the ability to
    audit / track or even upgrade along the distro. Installing from source,
    is almost always the wrong solution; There are *some* places where it
    might be a workable solution, but really do you want your first line of
    machine defence to be from source ? Just the amount of effort needed to
    make something like that work is huge.

    - KB
  • Walter Haidinger at Sep 1, 2011 at 2:08 am

    Am 31.08.2011 15:35, schrieb Karanbir Singh:
    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
    And at that point you lose. All management capability or the ability to
    audit / track or even upgrade along the distro. Installing from source,
    is almost always the wrong solution; There are *some* places where it
    Yes, it should be an exception. I wanted to present a fix to the OP problem.
    The correct solution would be to point him to a repository from where he can
    install/update a newer iptables package. Unfortunately, I don't know any.

    Installing from source should be considered the "quick & dirty" solution.
    That is why I install to a _distinct_ /opt directory, _not_ overwriting
    any rpm-owned files, and set the path to it only where needed, not globally.

    Your advice holds true if one is not careful to keep the distro "clean",
    i.e. prevent mixing it with non-distro files when running just running
    configure without --prefix (thus installing to /usr/local or, even worse,
    to /usr) or by installing "alien" other-distro rpm packages.

    Maybe it should be emphasized that it is _critical_ to keep a "clean"
    distribution. Otherwise yes, I absolutely agree with your statement above.

    Installing a few packages to a distinct directory don't hurt cleanliness,
    IMHO. It is not in the PATH by default and can easily be "uninstalled" by
    a "rm -r /opt/foo".

    Not to forget: Any manually installed package must be maintained anyways,
    regardless if built from source or installed by rpm.
    might be a workable solution, but really do you want your first line of
    machine defence to be from source ? Just the amount of effort needed to
    make something like that work is huge.
    In my particular case, the new iptables are _only_ used to fill the mangle
    table. Anything else is done by the stock iptables, so only the QoS rules
    would be affected. Not that critical.

    Of course, when running a newer (read: unsupported) kernel, such as 2.6.32
    or 2.6.35, on CentOS 5, you'd better verify everything works for you in a test
    environment before deploying it in the wild.

    Regards,
    Walter
  • Lamar Owen at Aug 31, 2011 at 9:01 am

    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.
  • Always Learning at Aug 31, 2011 at 9:18 am

    On Wed, 2011-08-31 at 09:01 -0400, Lamar Owen wrote:
    On Tuesday, August 30, 2011 10:24:41 PM Always Learning wrote:

    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.
    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

    * install to a different location

    * how to install it

    The server provider's suggestion

    modprobe ipt_string

    did not work so I have mention to them the OpenVZ comments made by
    several posters.
    ... OpenVZ container (VPS) ... is so different from 'real' CentOS.
    So I am observing.

    Thank you.

    Paul.
  • Lamar Owen at Aug 31, 2011 at 9:54 am

    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.
  • Always Learning at Aug 31, 2011 at 10:00 am

    On Wed, 2011-08-31 at 09:54 -0400, Lamar Owen wrote:

    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
    The service provider has suggested it needs the xt_tcpudp module which
    involves a kernel change. I'll try that. All I want to do is to stop the
    hacker, who is now targeting a different web site with the well-known
    phpmyadmin variations.

    Paul.

    --
    With best regards,

    Paul.
    England,
    EU.
  • Walter Haidinger at Sep 1, 2011 at 2:35 am

    Am 31.08.2011 15:18, schrieb Always Learning:
    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
    No stock OpenVZ kernel, see http://download.openvz.org/kernel/branches/
    for the available OpenVZ kernel branches. 2.6.32 is the most recent.
    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
    * install to a different location
    * how to install it
    Please note that wanted to provide fix to your problem, which is hardly
    an ideal solution. You might want to read my reply to KB post and
    my emphasis on keeping a "clean" distribution.
    The server provider's suggestion

    modprobe ipt_string
    So your kernel is missing the required iptables kernel module too.
    I really doubt that you've permission to load a kernel module from
    inside of an OpenVZ container. AFAIK this must be done on the host.

    Once the kernel module is loaded, you can try if your stock iptables
    works. If not, you'll have to try a newer release as I suggested in the
    first place.
    So I am observing.
    Thank you.
    Good luck, you're welcome.

    Regards,
    Walter
  • Mike at Aug 31, 2011 at 9:57 am
    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.
  • Always Learning at Aug 31, 2011 at 10:22 am
    Hi Mike,
    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.
    I'm definitely going to try '-m string' providing the service provider
    can fix the problem.

    I am not, as the article suggested, going to filter on a "28-byte
    string". If I was going to trap the http error 400 event
    'w00tw00t.at.ISC.SANS', I would filter on port 80 for 'w00t' or '.at' or
    'ISC' or 'SAN' because no web page name contains those strings. Having
    control over web pages names brings some benefits :-)

    In the current 4,000 to 6,000 daily hits, the lunatic uses

    login.php
    contact.php
    forgotten_password.php

    so I will filter port 80 traffic for that web site, now on its own IP,
    for

    log
    con
    pas

    because no web page name contains any of those 3 byte strings. The
    second defence is its own IP Table with 110 IP addresses. The lunatic
    has not added any new ones in the last 24 hours.

    The longest packet recently rejected was 496 bytes (from another hacker)
    and the current lunatic's packets are 60 bytes. Optimistically I have a
    reasonable prospect of trapping the above 3 byte strings.

    Thank you.

    Paul.
  • John R Pierce at Aug 31, 2011 at 11:07 am

    On 08/31/11 7:22 AM, Always Learning wrote:
    In the current 4,000 to 6,000 daily hits, the lunatic uses

    login.php
    contact.php
    forgotten_password.php
    your 'lunatic' aka 'hacker' is undoubtably a blind script ('bot')
    running on distributed previously hacked hosts, and probing a long long
    list of targets of which your hosts only a tiny part of. 4000 hits a
    day to 404 pages is background noise.


    --
    john r pierce N 37, W 122
    santa cruz ca mid-left coast
  • Always Learning at Aug 31, 2011 at 11:15 am

    On Wed, 2011-08-31 at 08:07 -0700, John R Pierce wrote:
    On 08/31/11 7:22 AM, Always Learning wrote:
    In the current 4,000 to 6,000 daily hits, the lunatic uses

    login.php
    contact.php
    forgotten_password.php
    your 'lunatic' aka 'hacker' is undoubtably a blind script ('bot')
    running on distributed previously hacked hosts, and probing a long long
    list of targets of which your hosts only a tiny part of. 4000 hits a
    day to 404 pages is background noise.
    I would like to use the facilities in the excellent Centos operating
    system to reduce hacking attacks. Implementing an IP Tables string
    facility is a useful learning experience. When that works, I'll try
    'recent'. Dangerous to ignore any background noise - far better to
    firmly shut the door and fill-in all known holes.

    Paul.
  • Lamar Owen at Aug 31, 2011 at 1:01 pm

    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.
  • Always Learning at Aug 31, 2011 at 1:33 pm

    On Wed, 2011-08-31 at 13:01 -0400, Lamar Owen wrote:

    On today's Internet you are simply not going to catch 100% of the
    attacks, full stop.
    Rather than being a willing or passive victim to 100% of the attacks, I
    aim to reduce the penetrability of most of them.

    Paul.
  • John R Pierce at Aug 31, 2011 at 1:38 pm

    On 08/31/11 10:33 AM, 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.
    an attempted access of a non-vunerability won't be any more effective
    the millionth time its run than the first time. its the unknown
    vunerabilities that get you, and your approach will do nothing for these.



    --
    john r pierce N 37, W 122
    santa cruz ca mid-left coast
  • Always Learning at Aug 31, 2011 at 1:44 pm

    On Wed, 2011-08-31 at 10:38 -0700, John R Pierce wrote:
    On 08/31/11 10:33 AM, 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.
    an attempted access of a non-vunerability won't be any more effective
    the millionth time its run than the first time.
    It can be effective especially if the IP address is blocked
    (indefinitely or temporarily).
    its the unknown vunerabilities that get you, and your approach will
    do nothing for these.
    Wrong because the IP address used for the unknown attack may have been
    blocked previously by the procedures already described.


    Paul.
  • Lamar Owen at Aug 31, 2011 at 1:55 pm

    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.
  • Always Learning at Aug 31, 2011 at 2:00 pm

    On Wed, 2011-08-31 at 13:55 -0400, Lamar Owen wrote:
    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.
    I'll be satisfied with 99% and that time and effort investment can be
    introduced on multiple servers and VPS and, when suitable, on laptops
    etc.

    Paul.
  • Louis Lagendijk at Aug 31, 2011 at 4:08 pm

    On Wed, 2011-08-31 at 19:00 +0100, Always Learning wrote:
    On Wed, 2011-08-31 at 13:55 -0400, Lamar Owen wrote:
    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.
    Still useless: it is not the attacks that you know about and that show
    themselves as errors in your logs (and filter from the log, that is the
    only gain), but those where you have a real security hole that you have
    to worry about. And those will be exploited from one of the many other
    bots in the hackers botnet.
    An empty log may give you a nice feeling of security, but it is false...
    A lot of work, but very little if any gain.
    Louis
  • Always Learning at Aug 31, 2011 at 5:23 pm

    On Wed, 2011-08-31 at 22:08 +0200, Louis Lagendijk wrote:
    On Wed, 2011-08-31 at 19:00 +0100, Always Learning wrote:
    On Wed, 2011-08-31 at 13:55 -0400, Lamar Owen wrote:
    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.
    Still useless: it is not the attacks that you know about and that show
    themselves as errors in your logs (and filter from the log, that is the
    only gain), but those where you have a real security hole that you have
    to worry about. And those will be exploited from one of the many other
    bots in the hackers botnet.
    Geachte Louis,

    Ik ben niet hek ook niet stom!

    Ik weet het wel dat it is the undetected attacks that potentially can
    cause most damage. Perhaps I know this better than most people because
    when I first got a Centos VPS, and it was doing nothing, a partially
    installed Horde provided a entry for some Romanians who used that server
    as a IRC host. It was careful reading of the logs which revealed the
    successful break-in. I therefore highly recommend reading the various
    logs because they may reveal unusual happenings.
    An empty log may give you a nice feeling of security, but it
    is false...
    A lot of work, but very little if any gain.
    Onzin. An empty log never ever gives me a sense of security because the
    first thing I am thinking is why is the log empty. Sensitive
    applications have a self-generated log stored away from the conventional
    logs and regularly perused.

    My logic to is seal-off as many potential accesses as possible. Your
    logic seems to be "do not bother because the successful attack will be
    unexpected". Ik ben zeker niet eens met jouw. I certainly disagree with
    that philosophy.

    ADULT EDUCATION ADVERTISEMENT

    The more one does in Centos investigating things and sealing-off IPs and
    ports and experimenting with IP Tables etc., the more one learns about
    the functioning of the Centos operating system. This acquired learning
    evolves into skills and is beneficial. Its acquisition will encourage
    people to understand more about their Centos installation(s) and make
    them more aware of the various risks and the wonderful things Centos can
    offer.

    Hoogachtend of mvg,

    Paul.
  • Craig White at Aug 31, 2011 at 7:11 pm

    On Aug 31, 2011, at 1:08 PM, Louis Lagendijk wrote:
    On Wed, 2011-08-31 at 19:00 +0100, Always Learning wrote:
    On Wed, 2011-08-31 at 13:55 -0400, Lamar Owen wrote:
    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.
    Still useless: it is not the attacks that you know about and that show
    themselves as errors in your logs (and filter from the log, that is the
    only gain), but those where you have a real security hole that you have
    to worry about. And those will be exploited from one of the many other
    bots in the hackers botnet.
    An empty log may give you a nice feeling of security, but it is false...
    A lot of work, but very little if any gain.
    Louis
    ----
    you're wasting your breath - I tried to tell him that a week ago but he only hears his own thoughts anyway.

    More to the point, he disables SELinux and then spends hours trying to improve security.

    Craig
  • Always Learning at Aug 31, 2011 at 7:28 pm

    On Wed, 2011-08-31 at 16:11 -0700, Craig White wrote:
    More to the point, he disables SELinux and then spends hours trying to
    improve security.
    Tell the world the ENTIRE story.

    Disabled it because things would not run. Said publicly in the last 7
    days will find time to learn about Selinux and the details of the file
    description blocks which SElinux appear to use.

    I am trying to filter-out some web page access attepts in IP Tables.
    When will you accept that has nothing to do with Selinux ?

    Have a nice day.

    Paul.
  • John R. Dennison at Aug 31, 2011 at 8:28 pm

    On Thu, Sep 01, 2011 at 12:28:01AM +0100, Always Learning wrote:
    Tell the world the ENTIRE story.
    That you never listen to anyone but yourself? I'm confident that this
    is a known fact.
    I am trying to filter-out some web page access attepts in IP Tables.
    When will you accept that has nothing to do with Selinux ?
    About the same time you realize that it's futile and selinux will
    compartmentalize any risk if it was to occur.

    Hint: your way isn't always, nor is it even often, the best way.




    John
    --
    The first lesson of economics is that we live in a world of scarcity.
    There is never enough of anything to satisfy all those who want it. The
    first lesson of politics is to ignore the first lesson of economics.

    -- Thomas Sowell (1930-), American economist and political commentator
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110831/6dbf45ac/attachment.bin
  • John R Pierce at Aug 31, 2011 at 9:06 pm

    On 08/31/11 4:28 PM, Always Learning wrote:
    Disabled it because things would not run.
    Always Talking. Never Learning.



    --
    john r pierce N 37, W 122
    santa cruz ca mid-left coast
  • Always Learning at Aug 31, 2011 at 9:09 pm

    On Wed, 2011-08-31 at 18:06 -0700, John R Pierce wrote:
    On 08/31/11 4:28 PM, Always Learning wrote:
    Disabled it because things would not run.
    Always Talking. Never Learning.
    Always Learning despite the taunts !


    Paul.
  • Ned Slider at Sep 1, 2011 at 1:50 am

    On 01/09/11 00:28, Always Learning wrote:
    On Wed, 2011-08-31 at 16:11 -0700, Craig White wrote:
    More to the point, he disables SELinux and then spends hours trying to
    improve security.
    Tell the world the ENTIRE story.

    Disabled it because things would not run. Said publicly in the last 7
    days will find time to learn about Selinux and the details of the file
    description blocks which SElinux appear to use.

    I am trying to filter-out some web page access attepts in IP Tables.
    When will you accept that has nothing to do with Selinux ?
    It has EVERYTHING to do with SELinux because SELinux is designed to
    mitigate those security risks you are trying to prevent reaching httpd
    with IPTables as well as those you do not even know about yet.

    Security is not a product. It's not about one component. It's a process.
    The best security uses layers of defence, of which IPtables is just one
    layer. SELinux is another layer. Use the right tools for the job. Better
    still, use ALL of the tools available to you rather than concentrating
    all your time on one tool whilst leaving every other door wide open.

    Even if you can't fix it, turn ON SELinux and put it in permissive mode.
    It will allow shit to happen, but at least then it will WARN you that
    shit is happening. Better still, just fix the issues.
  • Mark Roth at Aug 31, 2011 at 11:16 am

    John R Pierce wrote:
    On 08/31/11 7:22 AM, Always Learning wrote:
    In the current 4,000 to 6,000 daily hits, the lunatic uses

    login.php
    contact.php
    forgotten_password.php
    your 'lunatic' aka 'hacker' is undoubtably a blind script ('bot')
    running on distributed previously hacked hosts, and probing a long long
    list of targets of which your hosts only a tiny part of. 4000 hits a
    day to 404 pages is background noise.
    Maybe not, for a small website. However, let me re-suggest fail2ban, with
    three lines from one of our config files:
    failregex = <HOST> -.*"GET .*(php|pma|PMA|p/m/a|db|sql|admin).*/(config/c
    onfig\.inc|main)\.php.*".*404.*
    ^<HOST> -.*"GET .*(phpmyadmin).*\.php.*".*404.*
    ^<HOST> -.*"GET /w00tw00t\.at

    mark
  • Always Learning at Aug 31, 2011 at 11:22 am

    On Wed, 2011-08-31 at 11:16 -0400, m.roth at 5-cent.us wrote:

    Maybe not, for a small website. However, let me re-suggest fail2ban, with
    three lines from one of our config files:
    failregex = <HOST> -.*"GET .*(php|pma|PMA|p/m/a|db|sql|admin).*/(config/c
    onfig\.inc|main)\.php.*".*404.*
    ^<HOST> -.*"GET .*(phpmyadmin).*\.php.*".*404.*
    ^<HOST> -.*"GET /w00tw00t\.at
    Mark,

    Looking at your example seems to suggest Fail2Ban is an 'after the
    event' response. I would like to implement 'before the event' filtering
    which prevents, even on the first detected hacking attempt, anything
    reaching HTTPD.

    Paul.
  • Bowie Bailey at Aug 31, 2011 at 11:29 am

    On 8/31/2011 11:22 AM, Always Learning wrote:
    On Wed, 2011-08-31 at 11:16 -0400, m.roth at 5-cent.us wrote:

    Maybe not, for a small website. However, let me re-suggest fail2ban, with
    three lines from one of our config files:
    failregex = <HOST> -.*"GET .*(php|pma|PMA|p/m/a|db|sql|admin).*/(config/c
    onfig\.inc|main)\.php.*".*404.*
    ^<HOST> -.*"GET .*(phpmyadmin).*\.php.*".*404.*
    ^<HOST> -.*"GET /w00tw00t\.at
    Mark,

    Looking at your example seems to suggest Fail2Ban is an 'after the
    event' response. I would like to implement 'before the event' filtering
    which prevents, even on the first detected hacking attempt, anything
    reaching HTTPD.
    I assume this is an Apache server. Have you looked at mod_security
    (http://www.modsecurity.org/)? It is available from the epel
    repository. There is a bit of a learning curve to get it running, but
    it protects against a ton of hacking attempts.

    --
    Bowie
  • Always Learning at Aug 31, 2011 at 11:32 am

    On Wed, 2011-08-31 at 11:29 -0400, Bowie Bailey wrote:

    I assume this is an Apache server. Have you looked at mod_security
    (http://www.modsecurity.org/)? It is available from the epel
    repository. There is a bit of a learning curve to get it running, but
    it protects against a ton of hacking attempts.
    Thank you very much for that helpful suggestion. I'll look now.

    Paul.
  • Bowie Bailey at Aug 31, 2011 at 11:51 am

    On 8/31/2011 11:32 AM, Always Learning wrote:
    On Wed, 2011-08-31 at 11:29 -0400, Bowie Bailey wrote:

    I assume this is an Apache server. Have you looked at mod_security
    (http://www.modsecurity.org/)? It is available from the epel
    repository. There is a bit of a learning curve to get it running, but
    it protects against a ton of hacking attempts.
    Thank you very much for that helpful suggestion. I'll look now.
    Just keep a close eye on it at first. The current version tends to be
    *very* aggressive. I had to modify or disable several rules to get it
    to play nice with my websites.

    --
    Bowie
  • Always Learning at Aug 31, 2011 at 12:02 pm

    On Wed, 2011-08-31 at 11:51 -0400, Bowie Bailey wrote:
    On 8/31/2011 11:32 AM, Always Learning wrote:
    On Wed, 2011-08-31 at 11:29 -0400, Bowie Bailey wrote:

    I assume this is an Apache server. Have you looked at mod_security
    (http://www.modsecurity.org/)? It is available from the epel
    repository. There is a bit of a learning curve to get it running, but
    it protects against a ton of hacking attempts.
    Thank you very much for that helpful suggestion. I'll look now.
    Just keep a close eye on it at first. The current version tends to be
    *very* aggressive. I had to modify or disable several rules to get it
    to play nice with my websites.
    Thank you.

    Paul.
  • Mark Roth at Aug 31, 2011 at 11:32 am

    Always Learning wrote:
    On Wed, 2011-08-31 at 11:16 -0400, m.roth at 5-cent.us wrote:

    Maybe not, for a small website. However, let me re-suggest fail2ban,
    with
    three lines from one of our config files:
    failregex = <HOST> -.*"GET
    .*(php|pma|PMA|p/m/a|db|sql|admin).*/(config/c
    onfig\.inc|main)\.php.*".*404.*
    ^<HOST> -.*"GET .*(phpmyadmin).*\.php.*".*404.*
    ^<HOST> -.*"GET /w00tw00t\.at
    Looking at your example seems to suggest Fail2Ban is an 'after the
    event' response. I would like to implement 'before the event' filtering
    which prevents, even on the first detected hacking attempt, anything
    reaching HTTPD.
    It is an after the event: after 3? 5? (I forget the default, but that can
    be configured), it adds a rule to iptables to ban that IP for a limited
    time. That, too, can be changed; I haven't done it, but I'd be surprised
    if you can't configure it to ban that IP permanently.

    mark
  • John R Pierce at Aug 31, 2011 at 11:41 am

    On 08/31/11 8:22 AM, Always Learning wrote:
    Looking at your example seems to suggest Fail2Ban is an 'after the
    event' response. I would like to implement 'before the event' filtering
    which prevents, even on the first detected hacking attempt, anything
    reaching HTTPD.
    so you want another piece of software to parse the http protocol and
    analyze the traffic, before passing it on to your web server, which is
    going to parse the http protocol and deliver content? good luck with that.

    of course, to even consider doing such you would have to, in very
    precise terms, define exactly what comprises a 'hacking attempt'. do
    you give this filter a list of all valid URLs and trigger your block on
    any that aren't on that list?

    anyways, the design of such would better be discussed on a security
    tools mail list as its a very general topic, there's nothing here even
    remotely centos specific.

    --
    john r pierce N 37, W 122
    santa cruz ca mid-left coast
  • Always Learning at Aug 31, 2011 at 12:00 pm

    On Wed, 2011-08-31 at 08:41 -0700, John R Pierce wrote:
    On 08/31/11 8:22 AM, Always Learning wrote:
    Looking at your example seems to suggest Fail2Ban is an 'after the
    event' response. I would like to implement 'before the event' filtering
    which prevents, even on the first detected hacking attempt, anything
    reaching HTTPD.
    so you want another piece of software to parse the http protocol and
    analyze the traffic, before passing it on to your web server, which is
    going to parse the http protocol and deliver content? good luck with that.
    No I do not want "another piece of software to parse the http protocol
    and analyze the traffic".

    IT Tables, in which I have great confidence and trust, can do it.

    Thank you for your 'good luck' wishes.
    of course, to even consider doing such you would have to, in very
    precise terms, define exactly what comprises a 'hacking attempt'. do
    you give this filter a list of all valid URLs and trigger your block on
    any that aren't on that list?
    My definition: a hacking attempt is deliberately, meaning not a typing
    error, sending an invalid web page request. Obviously one should exclude
    the 'standard' wrong URLs issued by some software like the M$ Office
    responses and crossdomain requests.

    Inspection in IP Tables is performed before the data is passed to HTTPD.
    Therefore it is impossible to determine, at that point in the
    transmission process, the validity of incoming HTTP requests. Only HTTPD
    can decide that issue.
    anyways, the design of such would better be discussed on a security
    tools mail list as its a very general topic, there's nothing here even
    remotely centos specific.
    IP Tables is and Centos Ops or Sys Admins or others may wish to deploy
    the IP Tables blocking suggestion.


    Paul.

Related Discussions

People

Translate

site design / logo © 2022 Grokbase