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 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.
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
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.
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
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.
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
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.
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
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
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
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.
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
On Tue, Aug 30, 2011 at 10:24 PM, Always Learning centos@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 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
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
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 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.
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.
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.
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
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.
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.
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.
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.
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 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.
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.
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.
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
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.
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
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.
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
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.
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
On Wed, 2011-08-31 at 11:16 -0400, m.roth@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.
On 8/31/2011 11:22 AM, Always Learning wrote:
On Wed, 2011-08-31 at 11:16 -0400, m.roth@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.
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.
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.
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.
Always Learning wrote:
On Wed, 2011-08-31 at 11:16 -0400, m.roth@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
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.
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.
On 08/31/11 9:00 AM, Always Learning wrote:
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.
iptables will filter on packet headers and such at layer 3, it can't and won't analyze the content of packets, regardless of your emotional attachments.
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.
I said precisely. computers don't understand 'deliberate' vs 'typing error', those are subjective measures.
On Wed, 2011-08-31 at 09:11 -0700, John R Pierce wrote:
iptables will filter on packet headers and such at layer 3, it can't and won't analyze the content of packets, regardless of your emotional attachments.
I believe IP Tables '-m string' will. If you think the custodians and maintainers of IP Tables are making untrue claims, you may wish to acquaint them with your disbelieve. However it might be prudent for you to read the following before telling the IP Tables folks they are wrong.
http://www.netfilter.org/ Net Filter : The Home of IP Tables
http://ipset.netfilter.org/iptables.man.html The IP Tables Manual
http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html Frozentux : Detailed Technical Explanation of TCP/UCP and IP Tables (2006)
http://wiki.archlinux.org/index.php/Simple_stateful_firewall_HOWTO Arch Linux : How To
http://wiki.centos.org/HowTos/Network/IPTables Centos How-To : IP Tables
http://www.centos.org/docs/5/html/5.2/Deployment_Guide/ch-iptables.html Centos Deployment Guide : Section 43.9
I said precisely. computers don't understand 'deliberate' vs 'typing error', those are subjective measures.
Wrong. Some can be determined by machine searching for 'known' invalid URL strings which are not remotely similar to valid web page names. Obviously this is site dependant. For example which accidentally typed URL contains login.php or password.php when nothing like those names are used in valid web page names ?
On 08/31/11 9:32 AM, Always Learning wrote:
Wrong. Some can be determined by machine searching for 'known' invalid URL strings which are not remotely similar to valid web page names.
there's an infinite number of invalid strings, and only a finite number of valid ones.
anyways, your webserver already filters these out, its not going to respond to an invalid URL with anything other than '404'. thats its job.
On Wed, 2011-08-31 at 10:17 -0700, John R Pierce wrote:
anyways, your webserver already filters these out, its not going to respond to an invalid URL with anything other than '404'. thats its job.
The 'error' is trapped; a PHP routine examines the URL for known (in a list) hacker strings; if an established 'hacker' string is detected the site's .htaccess file is updated with a 'deny from' statement; in all instances an email is sent to the systems' monitor.
Oh, and a suitable customised web page is displayed in response.
An improvement is the real-time adding of block IP commands to IP Tables.
Paul.
On Wed, Aug 31, 2011 at 12:17 PM, John R Pierce pierce@hogranch.com wrote:
Wrong. Some can be determined by machine searching for 'known' invalid URL strings which are not remotely similar to valid web page names.
there's an infinite number of invalid strings, and only a finite number of valid ones.
anyways, your webserver already filters these out, its not going to respond to an invalid URL with anything other than '404'. thats its job.
The idea isn't as crazy as it sounds - expensive firewalls offer the option to block URLs including known exploits and it is a much faster way to protect a farm of servers behind it than waiting for the OS vendor to come up with a service pack to make the servers less vulnerable.
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.
-
Always Learning -
Bowie Bailey -
Craig White -
John R Pierce -
John R. Dennison -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Louis Lagendijk -
m.roth＠5-cent.us -
Michael Schumacher -
Mike -
Ned Slider -
Steve Walsh -
Tom H -
Tru Huynh -
Walter Haidinger